Re: gnulib portability issues

[Rich Felker]

On Tue, Jun 12, 2012 at 06:21:24AM -0600, Eric Blake 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.
> 
> 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().

So isnanl is expected to be slower in every program that's using it
for legitimate arithmetic purposes for the sake of one program's ease
of implementing a non-standard and mostly useless feature? How often
have you heard of anybody running od to dump a file of raw LD80
values? If this feature is desired, the test for invalid
representations belongs in od itself, where the cost only affects od,
not in every single mathematical program.

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.

> > 3. The test for "POSIX compatible" getopt does not actually test for
> > POSIX compatibility, but for GNU semantics which are contrary to
> > POSIX. This is purely an issue of a misnamed test; if gnulib wants to
> > provide a replacement getopt with GNU semantics, that's okay, but it
> > should not tell the user that the host getopt is not "POSIX
> > compatible".
> 
> We've already separated the getopt module into tests for POSIX behavior
> vs. tests for GNU extension behavior.  Which particular aspect are you
> claiming is incorrectly attributed to POSIX behavior when it should be
> treated as GNU behavior instead?  And is this occurring when the
> getopt-gnu module is in use, or is it reproducible when using just the
> getopt-posix module?  Or is this just a case of inaccurate wording but
> accurate testing?

I was testing with GNU m4. The test that fails has non-option
arguments placed before options, and tests to see if it can get the
option with getopt.

Rich