Summary: | [gtk] parseFloat depends on locale setting | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Pierre-Luc Beaudoin <pierre-luc.beaudoin> | ||||
Component: | WebKitGTK | Assignee: | Alexey Proskuryakov <ap> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Major | CC: | alp, ap | ||||
Priority: | P2 | ||||||
Version: | 523.x (Safari 3) | ||||||
Hardware: | PC | ||||||
OS: | Linux | ||||||
Attachments: |
|
Description
Pierre-Luc Beaudoin
2007-11-27 11:54:07 PST
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. 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? 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. 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. 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).
Note: I didn't test this. Comment on attachment 17933 [details]
proposed fix
r=me
(In reply to comment #6) > Note: I didn't test this. Oh, we should add a regression test then! Committed revision 28771. I would expect a lot of js tests to fail on Linux with non-U.S. locales before this patch. |