Re: isnanl, printf, and non-IEEE values

[Bruno Haible]

Rich Felker wrote:
> > > 2. Several tests for isnanl and printf long double support are
> > > invalid. They are generating invalid LD80 representations that cannot
> > > occur as values ("pseudo-denormal", for example) and testing that
> > > isnanl and printf treat these as NAN. Per the C standard, there is no
> > > need to handle these bit patterns (attempting to use them as floating
> > > point values results in UB); all it does is make isnanl() slightly
> > > slower and larger, so I'm reluctant to change our isnanl to match
> > > gnulib's expectations.

Eric Blake replied:
> > Actually, there IS a need to handle these representations.  The 'od'
> > program in coreutils is an example of where POSIX requires us to handle
> > ANY bit pattern as given in an arbitrary input file as ANY other type of
> > number, including long doubles.  And that means that all possible bit
> > patterns, even the invalid LD80 representations that cannot occur as a
> > result of arithmetic, CAN occur via memory aliasing, and we really do
> > desire to output those as NaN via the use of isnanl().

The other justification for handling these representations was brought up
by Jim in the long thread that surrounded this glibc bug:
<http://sourceware.org/bugzilla/show_bug.cgi?id=4586>
<http://sourceware.org/ml/libc-alpha/2007-06/msg00001.html>
See also the summary in
<http://lists.gnu.org/archive/html/bug-gnulib/2007-09/msg00105.html>.

Namely, glibc was not only producing wrong output. glibc *crashed* when
you passed some floating-point value outside the IEEE range. Jim's
argument: A program can produce floating-point values from a multitude of
sources; one way is to read them binary-encoded from files.

In theory you would be right that data should be validated at the boundaries
of the program, that is, when they are read from outside sources. But no
program I know of does this for unconstrained floating-point numbers. Hence,
the easiest way to avoid programs from crashing or producing senseless
output is to treat non-IEEE values like NaNs. This is what we're doing in
gnulib.

> So isnanl is expected to be slower in every program that's using it
> for legitimate arithmetic purposes

Yes. But it will not be slower by much. The CPUs have an instruction for
'fpclassify'; you just need to pass the right bitmask to that instruction.

> for the sake of one program's ease
> of implementing a non-standard and mostly useless feature?

The ability to call printf on a 'long double' argument without risking a
crash is a "mostly useless feature"? Some people see it differently.

> considering printf broken, and replacing printf
> because of this, is a big issue. Replacing printf is non-trivial

Sure. That's why gnulib does it only after the autoconf test has determined
that there really is a problem with the system's printf implementation.

> Attempting to replace "big" functions like printf should be avoided
> unless absolutely necessary.

Have you seen how broken printf is on many systems?
<http://www.gnu.org/software/gnulib/manual/html_node/printf.html>

Bruno