Bug 16162 – [gtk] parseFloat depends on locale setting

• Component: WebKitGTK
• Status: RESOLVED FIXED

[Pierre-Luc Beaudoin]

Parsing a float with parseFloat() doesn't return the same result for all locales.    

Sample script:
<script>
var input = prompt("Enter 0,5 or 0.5");
var test = 0.5;
if(input != null)
    test = parseFloat(input);
alert(eval("test == 0.5"));
alert(eval("test == '0.5'"));
if(test == 0.5)
    alert("Works!");
else
    alert("Pain!");
</script>

Tests data:
en_US: 
Entering 0.5 will produce true, true, then Works!
fr_CA:
Entering 0.5 will produce false, true then Pain!
Entering 0,5 will produce true, false, then Works!

Expected results (if parseFloat shouldn't use locale):
en_US: 
Entering 0.5 will produce true, true, then Works!
fr_CA:
Entering 0.5 will produce true, true, then Works!
Entering 0,5 will produce false, false, then Pain! (I guess)

[Alexey Proskuryakov]

I can see how this can happen if USE_LOCALE is defined. Is it defined on Linux somehow?

We should probably just remove USE_LOCALE code from dtoa.cpp.

[Alp Toker]

ap: USE_LOCALE isn't defined in my build and I don't see immediately how it could be defined.

Pierre-Luc: Could I get a bit more information on this? Can you check to see if USE_LOCALE is defined in your dtoa.cpp?

[Pierre-Luc Beaudoin]

I don't have USE_LOCALE define in my build.  ( I added 
#ifdef USE_LOCALE 
garbage  
#endif
in dtoa.cpp and it still compiles). 

This bug should affect anyone using a locale that uses a coma as the decimal point: French, Finish... all non-imperial unit locales I guess.

[Alexey Proskuryakov]

Actually, I'm quite sure that parseFloat works correctly. It seems that literals are parsed wrong!

In lexer.cpp, see:
    dval = strtod(m_buffer8.data(), 0L);

It should be kjs_strtod. I'd also recommend removing USE_LOCALE code from dtoa.cpp, to reduce future confusion.

[Alexey Proskuryakov]

Created attachment 17933 [details]
proposed fix

This bug could affect Mac, too, if an application using JavaScriptCore has set a C locale.

We also use strtol in date_object.cpp, but they all seem to be safe (it's only whitespace-skipping that can be affected AFAIK).

[Alexey Proskuryakov]

Note: I didn't test this.

[Darin Adler]

Comment on attachment 17933 [details]
proposed fix

r=me

[Darin Adler]

(In reply to comment #6)
> Note: I didn't test this.

Oh, we should add a regression test then!

[Alexey Proskuryakov]

Committed revision 28771.

[Alexey Proskuryakov]

I would expect a lot of js tests to fail on Linux with non-U.S. locales before this patch.