Re: CVS commit: src/tests/lib/libc/locale

[Taylor R Campbell <campbell+netbsd-source-changes-d%mumble.net@localhost>]

> Date: Tue, 28 Nov 2017 05:32:45 +0700
> From: Robert Elz <kre%munnari.OZ.AU@localhost>
> 
> Way back when I first learned floating point programming (something I
> have done astonishingly little of in the intervening decades) I was
> told it was *always* wrong to compare floats for exact equality - but
> of course, that was back in the days when almost all computing was
> numerical (simultaneous equation solfving, ffts, ...) and almost all
> written in fortran (the only language worthy of using) ...

That's sensible advice for most questions that a numerical algorithm
is likely to want to ask in the course of its computation, and when
the operations you're performing do not have 0.5 ulp error bounds.
(As general advice, usually you want to use relative error, namely
|actual - expected|/expected, not absolute error, |actual - expected|,
but that's an side.)

However, in this case, we are testing the map from a decimal expansion
to a floating-point number.  Under IEEE 754-2008, this operation is
required to be correctly rounded for decimal expansions of up to 20
significant digits (Sec. 5.12.2 `Details of conversion between
floating-point data and external character sequences', pp. 31--32).

Since every number here has 11 significant digits, the result must be
identical from the compiler and from strtod unless one or the other is
buggy.

Can you please put it back to an exact equality test and report the
mismatched values in the output, with %a rather than (or in addition
to) %g so that we can see the precise difference in their bits when
the test fails?