[Webkit-unassigned] [Bug 150386] Safari 8 and 9 have a Date bug with the "milliseconds" param.

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=150386

--- Comment #3 from Darin Adler <darin at apple.com> ---
The Date constructor code already treats the millisecond parameter as a double rather than an integer to avoid the 32-bit integer clamping problems. The problem is simply in the input validation. Here is the code validating the seventh argument in the millisecondsFromComponents function in DateConstructor.cpp:

!std::isfinite(doubleArguments[6]) || (doubleArguments[6] > INT_MAX) || (doubleArguments[6] < INT_MIN)

As you can see, it’s incorrectly comparing with 32 bit integer minimums and maximums; that’s where the bug comes from. (The code has no business using INT_MIN and INT_MAX for 32-bit integer range checking anyway.) The fix will be to write a corrected version of this range checking or possibly to remove it entirely. Someone just needs to figure out what the limits need to be.

The “any 64-bit signed integer” idea isn’t compatible with JavaScript’s usual type model; integer values are typically treated as a subset of double values rather than a distinct type with values not representable as doubles. Seems highly unlikely that is required, and equally unlikely that it is supported in other JavaScript engines. If this does turn out to be required, there will be substantial design and implementation work required to resolve this and it won’t just be a simple bug fix.

To make it easy to fix the bug we need a test case that covers the values as the limits of what are allowed for Date, and it would be worthwhile to both try the test cases on other browsers and perhaps make it part of an ES6 test suite.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20151024/f871fad3/attachment-0001.html>