OLEAUT32 (resend) Floating point locale, no negative zero
Alex Villacís Lasso
a_villacis at palosanto.com
Mon May 30 15:07:42 CDT 2005
Alexandre Julliard wrote:
> Alex Villacis Lasso <a_villacis at palosanto.com> writes:
>> * 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
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
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
More information about the wine-devel