Re: gnulib portability issues

[Rich Felker]

On Tue, Jun 12, 2012 at 08:02:58AM -0600, Eric Blake wrote:
> > If you were just using gnulib to replace isnanl in od, it wouldn't be
> > such an issue. But considering printf broken, and replacing printf
> > because of this, is a big issue. Replacing printf is non-trivial, and
> > might not even work (for instance if your replacement of printf
> > happens to call some standard library function that the implementation
> > happened to implement in terms of printf, you get infinite recursion).
> > Attempting to replace "big" functions like printf should be avoided
> > unless absolutely necessary.
> 
> You have a fair argument here, but Bruno needs to weigh in on it since
> it was his decision to mark printf 'broken' when handed undefined input.
>  I agree with you that printf("%Ld",n) not printing "NaN" for undefined
> input is a much different case than isnanl(n) not returning true for
> out-of-range input.

To me, the only difference is the pain of replacing them. You cannot
have these bit patterns in an LD80 without your program having invoked
undefined behavior (accessing an object as a type other than its
effective type or one of the allowed exceptions), so there's no
fundamental reason either should handle it. In fact it's conceivable
that machines could exist where even just loading the bit pattern into
a floating point register would generate a signal, so really od should
be performing the test on the unsigned char[] array *before*
reinterpreting it to LD80 rather than calling a function that takes an
LD80 argument to make the test..

> It would indeed be feasible to say that printf() is
> POSIX compatible if it correctly handles all inputs that are only
> possible via defined arithmetic, and require that programs like od that
> translate bit patterns into numbers outside of arithmetic take extra
> steps to sanitize pseudo-denormals into something that will be printed
> correctly rather than blindly pass all bit patterns to printf directly.
>  That may still require an isnanl() replacement, but hopefully Bruno
> would agree that a printf() replacement is overkill.

I have no objection to this isnanl replacement (from my perspective,
it's akin to your replacement of malloc when malloc(0) returns 0...)
but I don't think it should be called a check for C99 or POSIX
conformance. It should be called a check for handling invalid bit
representations or something similar.

> GNU m4 requires the GNU extensions to getopt; so this may be a case of
> just inaccurate wording in the configure output.  Also, the last release

Indeed, my original report was just that it's inaccurate wording in
the test output. It caused me to go looking for conformance bugs in
out getopt, only to find that gnulib was not actually testing for
POSIX but GNU.

Rich