Alexandre Julliard escribió:
Alex Villacís Lasso a_villacis@palosanto.com writes:
@@ -4159,7 +4161,9 @@ { WCHAR buff[256];
- setlocale(LC_ALL, "C"); sprintfW( buff, szFloatFormatW, fltIn );
- setlocale(LC_ALL, ""); return VarDecFromStr(buff, LOCALE_EN_US, 0, pDecOut);
You can't do that, setlocale() affects the whole process. In any case we shouldn't need to go through a string to convert a float to a decimal.
Module: wine Branch: master Commit: ed58b1bad0f565b8a609803e29dbadfff651b444 URL: http://source.winehq.org/git/wine.git/?a=commit;h=ed58b1bad0f565b8a609803e29...
Author: Alexandre Julliard julliard@winehq.org Date: Tue Nov 7 18:24:15 2006 +0100
kernel32: Better workaround for the lack of locale environment variables on MacOS.
This patch added the setlocale(LC_ALL, "") line to dlls/kernel32/locale.c . The oleaut32 tests for vartype.c have been failing since that time on non-English locales. I see now that setting the locale around calls of sprintfW() is not thread-safe. However, I think there is no big problem on going through a string in order to convert a floating-point number into a DECIMAL, since otherwise, we would need to implement our own bit-splicer for floating-point numbers. As long as the starting locale for sprintfW() is known to be the LC_NUMERIC="C", all other parsing should work as before the MacOS patch. Therefore I propose the attached patch. This patch simply sets setlocale(LC_NUMERIC, "C") at the end of LOCALE_Init() in dlls/kernel32/locale.c in order to guarantee that sprintfW will always use periods as decimal separators.
Changelog: * Add setlocale(LC_NUMERIC, "C") after locale init in order to guarantee that initial numeric strings use a period as decimal separator. Fixes oleaut32 tests in non-English locales.