Bug 31349 – String to number coercion is not spec compliant

• Component: JavaScriptCore
• Status: RESOLVED FIXED

[kangax]

As explained here (http://thinkweb2.com/projects/prototype/sputniktests-web-runner/#number-u00A0), `Number('\u00A0')` returns `NaN` in WebKit, but should be `0`. Similarly, `parseFloat(“\u205F -1.1”)` returns `NaN` but should be `-1.1`. 

See 9.3.1 (ToNumber Applied to the String Type); in particular, StrWhiteSpaceChar production.

[Alexey Proskuryakov]

We already have bug 25490 for nbsp. Maybe we should make this a duplicate, and extend the scope of the former to cover U+205F MEDIUM MATHEMATICAL SPACE.

[kangax]

Sure, marking as duplicate of 25490 would make sense. 

Speaking of separate tickets, would you rather have all Sputniktests failures (http://kangax.github.com/sputniktests-webrunner/) summed up in one ticket, or should I file them separately?

[kangax]

I would also like to add that not only U+00A0 and U+205F fail, but practically the entire Zs whitespace category — U+2000-U+200A, U+2028, U+2029, and others.

[Brian Foley]

Created attachment 46747 [details]
Show parseFloat failure with non-CString characters

[Brian Foley]

This problem still exists with Safari 4.0.4 and r53317. It appears to be a duplicate of #16717

[Derk-Jan Hartman]

Just ran into this issue on Wikipedia where we were trying to discover why a range (with the en dash) was not supported in a sortable table.

Bug 16717 indeed looks like a dupe of this. Bdash notes:

From ustring.cpp:
954      // FIXME: If tolerateTrailingJunk is true, then we want to tolerate
non-8-bit junk
955      // after the number, so is8Bit is too strict a check.
956      if (!is8Bit())
957        return NaN;

[Darin Adler]

*** This bug has been marked as a duplicate of bug 16717 ***

[Darin Adler]

Some aspects of this bug have been fixed, but others have not.

Specifically, there was a bug where all non-ASCII values would cause the conversion to fail. That was fixed. Here are the remaining problems that I know of:

    1) Whitespace other than U+0020 is not correctly skipped.

    2) Illegal UTF-16 sequences will cause parseFloat to fail.

There are comments about both of these problems in UString::toDouble that I added a while back when I noticed the mistakes.

[Darin Adler]

I’d like to fix these some time soon.

[Darin Adler]

Created attachment 61138 [details]
Patch

[Geoffrey Garen]

Comment on attachment 61138 [details]
Patch

r=me

[Darin Adler]

Committed r63120: <http://trac.webkit.org/changeset/63120>