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

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Tue, 28 Nov 2017 15:34:19 +0100
    From:        Joerg Sonnenberger <joerg%bec.de@localhost>
    Message-ID:  <20171128143418.GA8144%britannica.bec.de@localhost>

  | Hidding things until then doesn't actually fix something.

No, it doesn't, but when I made the change I wasn't hiding anything,
just doing what I thought was the correct programming technique.

  | You might try to printf them with %a instead.

Didn't know that existed, or I would have (like I said, I rarely use
floating point - mostly just for calculating percentages...) - I also
don't often read the printf(3) man page for that kind of detail.

  | The reference paper for precise conversion between binary and decimal
  | for floating point values is from 1990, which is quite surprisingly
  | late.

And well after my time.


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

  | (As general advice, usually you want to use relative error, namely |actual -
  | expected|/expected, not absolute error, |actual - expected|, but that's an
  | side.)

Yes, I know that ... but here the "expected" is a known constant, so
that part of the computation was done in my head (the tests do this kind
of thing all the time - they aren't supposed to be examples of good
programming technique, just to uncover problems ... this one isn't even
really testing floating point conversions, it is testing locales, making
sure that everything works with number conversion with different locale
settings.)   I thought a relative difference of 1e-12 would be insignificant
enough - there was a note about that in the original commit message.

  | 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.

I think that conclusion had been reached already (not by me...) but that's
"Under IEEE 754-2008" right?   What about architectures that don't use IEEE
floats?  This test should not be assuming that - we still support vax right?
The test should be able to be run there as well.   Can we guarantee that the
results must be identical on every port that runs NetBSD?   If not, then
expecting them to be identical (in this test) would be too much long term.
If we want tests that are intended to be tests of floating point conversions,
assuming there aren't some already, they'd belong somewhere other than in
a test of locales, and could be tailored to the various floating formats
that we might encounter.

  | 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?

Yes, doing that now (need to build and test twice, once with the "correct"
code, and once where the result of the test is deliberately forced to
fail so I can test the error string works as intended.)

The first of those is done (while I have been typing this e-mail) - now I
have to go do the "force fail" test.   After that waiting for b5 to actually
run the test will take about a day I expect.

In the interim, I'll see if I can set up an i386 testbed to see if I can
reproduce the issue there - I might manage to get that done quicker than
b5 runs the updated test.   Perhaps.    I haven't built an i386 system
(let alone run one) in ages...

kre

ps: if nothing else, this has at least finally gained this test failure
some attention, it has been consistently failing on i386 since about forever,
and seemed to simply be ignored - no-one was bothering to find out why it
was failing, it was just "one of those things" ...