[Webkit-unassigned] [Bug 9697] parseInt results may be inaccurate for numbers greater than 2^53

[bugzilla-daemon at webkit.org]

http://bugs.webkit.org/show_bug.cgi?id=9697


cwzwarich at uwaterloo.ca changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #15528|0                           |1
        is obsolete|                            |
  Attachment #15541|                            |review?
               Flag|                            |




------- Comment #14 from cwzwarich at uwaterloo.ca  2007-07-17 02:43 PDT -------
Created an attachment (id=15541)
 --> (http://bugs.webkit.org/attachment.cgi?id=15541&action=view)
Revised proposed patch

I fixed the problems mentioned in Darin's comments and added some test cases.
Here are some explanations of the cases that are maybe not as obvious:

(- 'infinity').toString()

This should be NaN, but will be Infinity if we don't check for the first three
letters. Note, this doesn't happen in the current version of toDouble(), but
that is because the current code will also miss things like "1e2000", which
should be Infinity but instead are NaN.

parseInt('0x100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000',
16)

This test and the one below demonstrate the necessity of the test for
radixMultiplier being infinite in the loop in parseIntOverflow(). If the
radixMultiplier becomes infinite, then the arithmetic below will make number
become NaN if any digit is zero. Hence we explicitly test for this in the code.
I added the decimal case as well for posterity, even though that is now handled
by strtod().

parseInt('9007199254740992e2000')
"parseInt('9007199254740992.0e2000')

These will give Infinity unless we check the input of strtod(). The second
demonstrates the necessity of checking for the decimal point as well.

The only test that will not fail no matter what changes to the code take place
between the current code and the code in my patch is the one testing the value
of

Number(0x1000000000000081).toString(16)

The hexadecimal conversion code in toDouble() is slightly different than
elsewhere, so it rounds differently and converts this correctly, but it fails
for other cases in the JS Core tests that are now fixed. I figured I'd add the
test in anyways since I  added it for the lexer and parseInt().

I believe that accounts for every branch.


-- 
Configure bugmail: http://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.