On 18 August 2015 at 01:13, Bernhard Übelacker bernhardu@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 '۵'.