[PATCH] msvcr120: Implement strtof and _strtof_l (try 3)

[Henri Verbeet]

On 18 August 2015 at 01:13, Bernhard Übelacker <bernhardu at vr-web.de> wrote:
>> As an aside, other potentially interesting things to test are the
>> decimal separator depending on locale, different number digits
>> depending on locale (e.g. "۰٫۲۵"), C99 hexadecimal floats, and
>> floating point specials like e.g. 1.#inf/INF/INFINITY.
>
> The tested values up to now were simple ones because the real
> implementaion is inherited from msvcrt.dll and the more detailed tests
> are probably there.
>
It looks like some of those are covered by test__strtod() in
dlls/msvcrt/tests/string.c, but not all of them. For what it's worth,
I think those tests would be useful things to know, but not
necessarily required to get an initial strtof() implementation
accepted.

> For the different number digits - this would be more subject to wcstof
> and _wcstof_l ?
>
Possibly, but that would be an interesting result on its own. MSDN
doesn't write a lot about the character set used for strtof(), but in
principle I'd expect it to interpret the string according to the
current ANSI codepage (CP_ACP).

> However, it took some time to find the meaning of "۰٫۲۵" ...
> I did some tests and only after changing formats in regional settings
> to Persian, on an otherwise german Windows, wcstof did correctly
Yeah, it would depend on that kind of regional setting. How about
_wcstof_l() with the appropriate locale?

> interpret "٠.٢۵" (ARABIC-INDIC DIGITs with an regular ',').
> "۰.۲۵" (EXTENDED ARABIC-INDIC DIGITs) did not work.
>
Odd.

> WCHAR floatm[] = {0x0660, 0x066b, 0x0662, 0x0665, 0}; /* L"٠٫٢۵" ARABIC-INDIC DIGIT */
0x0665 is '٥' not '۵'.