OLEAUT32: (resend) Floating point locale, no negative zero
Alex Villacis Lasso
a_villacis at palosanto.com
Mon May 2 12:24:41 CDT 2005
Alexandre Julliard wrote:
>Alex Villacis Lasso <a_villacis at palosanto.com> writes:
>
>
>
>>Changelog:
>>* Force Single|Double conversion to BSTR to use the decimal separator
>>defined by the current locale, because that is what native oleaut32
>>does, and to be consistent with later parsing of floating-point
>>numbers, which uses current locale. Failure to apply this patch causes
>>vartype test to fail in non-US locales with a decimal separator other
>>than a period.
>>* The number form "-0" is *not* allowed to be returned in a
>>Single|Double conversion to BSTR in case of numeric undeflow, use
>>unsigned zero instead. Some applications depend on this. Test included.
>>
>>
>
>That's ugly, I think we really want to do our own formatting instead
>of using the system printf and hacking the string afterwards.
>
>
>
I agree on the fact that the last patch was ugly, in the sense of using
memmove and such. However, the fact remains that there are Windows
applications that fail because floating-point formatting does not match
their expectations in negative zero, and in decimal separator usage.
Here is another version of the patch. This one builds a custom
NUMBERFMTW structure to specify an empty thousand-separator, and the
same number of decimal digits as the original unformatted number (I wish
there was an option to preserve the current number of decimal places,
but this is the next best thing). It then calls GetNumberFormatW to do
the job. In case of failure (I have seen it at least once in my sample
app), the unformatted numeric string is returned instead. I chose to
preserve the negative-zero hack because no option was found so far to
tell GetNumberFormatW to remove the sign of a floating-point zero, and I
don't dare to modify GetNumberFormatW if it is working as designed.
BTW, does anybody know what happened to the DECIMAL implementation I
sent (subject is: OLEAUT32: (resend) implement DECIMAL division,
(generic) multiplication and (generic) cast to string)? Nobody has
committed it (as gleaned from the wine-cvs mailing list), and nobody has
commented on it either. I can send it again if required, but I would
like to know why it is being ignored, so I can improve it.
Changelog:
* Force Single|Double conversion to BSTR to use the decimal separator
defined by the current locale, because that is what native oleaut32
does, and to be consistent with later parsing of floating-point numbers,
which uses current locale. Failure to apply this patch causes vartype
test to fail in non-US locales with a decimal separator other than a period.
* The number form "-0" is *not* allowed to be returned in a
Single|Double conversion to BSTR in case of numeric undeflow, use
unsigned zero instead. Some applications depend on this. Test included.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wine-oleaut32-vartype-locale_plus_negative_zero_resend_try2.patch
Type: text/x-patch
Size: 2975 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-patches/attachments/20050502/2f685e57/wine-oleaut32-vartype-locale_plus_negative_zero_resend_try2.bin
More information about the wine-patches
mailing list