CVS commit: [netbsd-8] src/tests/lib/libc/locale

["Manuel Bouyer" <bouyer%netbsd.org@localhost>]

Module Name:    src
Committed By:   bouyer
Date:           Thu Mar 15 11:24:46 UTC 2018

Modified Files:
        src/tests/lib/libc/locale [netbsd-8]: t_sprintf.c

Log Message:
Pull up following revision(s) (requested by martin in ticket #631):
        tests/lib/libc/locale/t_sprintf.c: revision 1.4
        tests/lib/libc/locale/t_sprintf.c: revision 1.5
        tests/lib/libc/locale/t_sprintf.c: revision 1.6
        tests/lib/libc/locale/t_sprintf.c: revision 1.7
Add some diagnostics to the strto test, so I can see why this
fails on i386 (on qemu) - will probably keep them when done.
When comparing doubles (any floating point values) which have been
computed using different methods, don't expect to achieve identical
results (here, one constant is perhaps converted to binary from a string by
a cross compiler, the other is converted at run time).   Allow them to
have a small difference (for now, small is < 1e-7 - the constant is ~ 1e5,
so this is 12 orders of magnitude less) before failing (and include the
actual difference in the error message if it does fail.)
Revert 1.4 (perhaps temporarily) and add even more diagnostics to those
added in 1.3 to see if it is possible to determine why the strict equality
test fails on i386, yet succeeds elsewhere.
Since the C standard allows for intermediate floating results to contain
more precision bits than the data type expects, but (kind of obviously)
does not allow such values to be stored in memory, expecting the value
returned from strtod() (an intermediate result) to be identical (that is,
equal) to a stored value is incorrect.
So instead go back to checking that the two numbers are very very close.
See comments added to the test for more explanation.


To generate a diff of this commit:
cvs rdiff -u -r1.1.2.2 -r1.1.2.3 src/tests/lib/libc/locale/t_sprintf.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.