OLEAUT32 (resend) Floating point locale, no negative zero

[Alex Villací­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.
>
>  
>
By "our own formatting", do you mean to reimplement the %f and %lf 
functionality of the system printf() in a Wine-specific function? It can 
be done, of course, but I thought there was a good reason for the 
original code to rely on the system printf() for the floating-point 
formatting. Then there is the question of whether the potential patch is 
still allowed to use GetNumberFormatW for the (dwFlags & LOCALE_USE_NLS) 
case. This function seems to relay on the decimal separator being a 
period (as built by sprintfW). A more recent patch I sent used 
GetNumberFormatW for the non-NLS case to achieve the substitution of the 
period for whatever the decimal separator was in the current locale. 
However, GetNumberFormatW() cannot do anything about the negative zero 
issue, so that was still handled in the VARIANT_BstrFromReal() function 
of vartype.c.

How much formatting should the new formatting function do? Is it enough 
to handle the negative zero and the decimal separator, and use 
sprintfW() for the LOCALE_USE_NLS case (as the current code does), or 
does it have to reimplement the functionality currently delegated to 
GetNumberFormatW()?

I will start making a patch assuming the first scenario (use new 
function just for non-NLS case). Please answer if anybody thinks it 
should be done otherwise.

Alex Villacís Lasso