OLEAUT32: (resend) Floating point locale, no negative zero

[Alex Villaci­s Lasso]

Alexandre Julliard wrote:

>Alex Villaci­s 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