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

[Henri Verbeet]

On 15 August 2015 at 15:55, Bernhard Übelacker <bernhardu at vr-web.de> wrote:
> It is not that inaccurate and yes, I did just copy from the ddraw tests.
>
> The constants I use in the test would allow for using 0 as ulps.
> If I understand correctly a direct comparison would then also be possible
> (at least on my system and testbot).
>
> So should we remove the compare_float altogether and use a direct
> comparison?
>
If you're careful about using values that are exactly representable
you can just use a simple compare, yeah. Arguably the more interesting
tests would be values that aren't exactly representable with different
FPU precision and rounding modes though.

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.

> And if not, how many representable floats difference whould be suitable?
> (The smallest value I see in other tests is 16.)
>
It depends on a lot of things, like what you're testing, how close you
need to match the Windows values and how much the values are expected
to differ between different machines because of e.g. hardware or
driver differences. In practice you'd start with something reasonable
and then either make the bounds tighter when you run into an
application that depends on those tighter bounds or looser when you
encounter more variance in the test results. For something like
strtof() it may actually be reasonable to compare to an specific
bit-pattern instead of a floating point value.