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.
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.
Alex Villacís Lasso a_villacis@palosanto.com writes:
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.
I put this in for now, but oleaut32 should really be fixed, we can't force the whole process to format number in English just because oleaut32 is broken. It doesn't matter too much for Wine itself, but any Unix library that we load should be able to behave properly according to the locale that the user has selected.
Alexandre Julliard escribió:
Alex Villacís Lasso a_villacis@palosanto.com writes:
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.
I put this in for now, but oleaut32 should really be fixed, we can't force the whole process to format number in English just because oleaut32 is broken. It doesn't matter too much for Wine itself, but any Unix library that we load should be able to behave properly according to the locale that the user has selected.
Well, here is an attempt to fix part of the breakage in oleaut32 that ties it to LC_NUMERIC being "C". This patch decomposes floats and doubles into the component bitfields, then copies the values into DECIMAL structures and manipulates them to get the corresponding DECIMAL value. This removes the step of converting the floating-point number into a string and therefore eliminates two uses of sprintfW on floats. This particular patch passes all tests, but I am not really sure about the rounding - I might be overdoing it. Please comment.
Changelog: * Remove uses of sprintfW to convert floats into DECIMAL by directly parsing the floating-point representation.
Alex Villacís Lasso
Alex Villacís Lasso escribió:
Alexandre Julliard escribió:
Alex Villacís Lasso a_villacis@palosanto.com writes:
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.
I put this in for now, but oleaut32 should really be fixed, we can't force the whole process to format number in English just because oleaut32 is broken. It doesn't matter too much for Wine itself, but any Unix library that we load should be able to behave properly according to the locale that the user has selected.
Well, here is an attempt to fix part of the breakage in oleaut32 that ties it to LC_NUMERIC being "C". This patch decomposes floats and doubles into the component bitfields, then copies the values into DECIMAL structures and manipulates them to get the corresponding DECIMAL value. This removes the step of converting the floating-point number into a string and therefore eliminates two uses of sprintfW on floats. This particular patch passes all tests, but I am not really sure about the rounding - I might be overdoing it. Please comment.
Changelog:
- Remove uses of sprintfW to convert floats into DECIMAL by directly
parsing the floating-point representation.
Alex Villacís Lasso
Resending since there was no response since Monday.