At least I suspect it's an issue with LLint: The JSFiddle test case work correctly in Mobile Safari on iOS6 (which uses the JIT), but fails in Chrome for iOS (which isn't allowed to use the JIT and thus falls back to LLint). A standalone version of libJavaScriptCore for iOS ( https://github.com/phoboslab/JavaScriptCore-iOS ) also has this problem on real hardware (again, using LLint), but works fine in the iPhone Simulator (using the classic interpreter). Number.MIN_VALUE is defined as 5E-324, but the smallest representable number with LLint seems to be somewhere in the 5E-308 range - console.log(5E-309) shows 0 again. An easy workaround would be to allow us to use the JIT on iOS ;-)
The smallest representable number is a per-process CPU setting, not controlled by JavaScriptCore.
Sorry, I don't understand. Even if it's a CPU setting, shouldn't JSC return _that_ current setting for MIN_VALUE instead of 0? In the JSC source, MIN_VALUE is set to a fixed value (5E-324).
In case it wasn't clear, I'm talking about the "Number" object in the JS runtime. Specifically, the Number Constructor. It has a property "MIN_VALUE" that you can access in JavaScript code. This works fine when using the JSC JIT (it returns 5E-309), but fails when using LLint (it returns 0). See 'numberConstructorMinValue' in NumberConstructor.cpp around line 109 https://svn.webkit.org/repository/webkit/trunk/Source/JavaScriptCore/runtime/NumberConstructor.cpp
In processes that don't support denormal doubles, 5E-309 rounds to 0.
Ok. So who is to blame? Is this an OS issue? Clearly MIN_VALUE should not be 0. From the ECMA standard ( http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf ): 15.7.3.3 Number.MIN_VALUE The value of Number.MIN_VALUE is the smallest positive value of the Number type, which is approximately 5E-324
Pardon my ignorance. TN2293 ( http://developer.apple.com/library/ios/#technotes/tn2293/_index.html ) explains a bit more. So I guess it is expected to always run JSC with support for denormal numbers enabled, correct? Wouldn't a fix where MIN_VALUE returns the _actual_ smallest representable number still make sense? I.e. if denormal support is enabled, return 5E-324, otherwise 5E-308.
> Wouldn't a fix where MIN_VALUE returns the _actual_ smallest representable number still make sense? I.e. if denormal support is enabled, return 5E-324, otherwise 5E-308. That sounds like a good idea. Why don't you file a new bug requesting that. (This bug is cluttered with a lot of confusing speculation about the LLInt, the JIT, and some third party software.)