Re: gnulib portability issues

[Eric Blake]

On 06/09/2012 06:39 PM, Rich Felker wrote:
> 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.

I think we're still discussing this, but hopefully coming to a workable
solution for everyone.

> 
> 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().

> 
> 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?

> 
> 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?

That seems to be the consensus, and I think this is very much
intertwined with the answer to your point 1.

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

It's list policy to reply-to-all anyways, so that only people that set
specific 'followup-to' headers get trimmed because they asked to be trimmed.

-- 
Eric Blake   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature