Re: Ryu floating point output patch

Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
> Funny thing: I've been devoting considerable effort to testing this, and
> the one failure mode I've found is very interesting; it's not a problem
> with strtod(), in fact it's a bug in our float4in caused by _misuse_ of
> strtod().

> In particular, float4in thinks it's ok to do strtod() on the input, and
> then round the result to a float.

Hm. I'm not sure how much weight to put on this example, since we don't
guarantee that float4 values will round-trip with less than 9 digits of
printed precision. This example corresponds to extra_float_digits = 1
which doesn't meet that minimum. However, I agree that it's rounding
the presented input in the less desirable direction.

> strtof() exists as part of the relevant standards, so float4in should be
> using that in place of strtod, and that seems to fix this case for me.

To clarify that: strtof() is defined in C99 but not older standards
(C89 and SUSv2 lack it).

While we've agreed that we'll require C99 *compilers* going forward,
I'm less enthused about supposing that the platform's libc is up to
date, not least because replacing libc on an old box is orders of
magnitude harder than installing a nondefault version of gcc.

As a concrete example, gaur lacks strtof(), and I'd be pretty much
forced to retire it if we start requiring that function. Putting
a more modern gcc on that machine wasn't too painful, but I'm not
messing with its libc.

But I'd not object to adding a configure check and teaching
float4in to use strtof() if available.

regards, tom lane