gnulib portability issues

[Rich Felker]

Hi,

Reuben suggested I contact upstream since we've been discussing on the
musl mailing list (address@hidden, archive at
http://www.openwall.com/lists/musl/) some of the difficulties that
have arisen out of gnulib and programs using it when building on musl
(http://www.etalabs.net/musl/). I'd like to apologize in advance if
some of our users (myself included) have been a bit harsh criticizing
gnulib; it's just been a constant source of frustration for us.

With that said, here's a summary of some of the issues we've run into:

1. freadahead is inherently non-portable and has no working portable
fallback version. At some point in the discussions, it was suggested
that this function should not be pulled in except on old broken
systems where stdio doesn't work and needs replacement functions.
However, at least some packages, notably GNU M4, seem to use it
directly.

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.

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

4. Some replacement functions in gnulib have special-cases for each of
a set of known-broken systems, with an #else case containing #error.
Some of them accept -DSLOW_BUT_NO_HACKS to avoid the error, but it's
not clear to me that most of them work, and it seems very undesirable
that programs should simply fail to build on unknown systems unless
the person running the build is aware of the obscure
-DSLOW_BUT_NO_HACKS solution. Wouldn't it be better to include
default-case code that works, and possibly issue a #warning that it
might perform suboptimally?

The most pressing issue I'd like to get fixed is the freadahead/m4
one. I'm not sure where the best place to fix it is, but right now it
leaves us with a major core system utility that can't build out of the
box on musl-based systems, and I can't see any way to work around the
issue on musl's end.

Please Cc me and Reuben on responses if that's okay since I'm not
subscribed and I believe he might have delivery disabled for this
list.

Rich