On 06/18/2012 06:11 PM, Rich Felker wrote:
> Some updates...
> 
> On Mon, Jun 18, 2012 at 12:49:44AM +0200, Bruno Haible wrote:
>> There is a recipe, in <http://sourceware.org/glibc/wiki/Testing/Gnulib>,
>> that explains how to use gnulib to check a libc against bugs. When I apply
>> this to musl-0.9.1, I get this list of problems:
>>
>> Replacements of *printf, because of
>> [...]
>>   checking whether printf survives out-of-memory conditions... no
> 
> No idea. Copying out the test and running it directly, it passes just
> fine for me. Maybe gnulib has already replaced printf with its own
> malloc-using version by the time it gets to this test??

No; configure-time tests are relatively independent, and all done prior
to any replacements at compile-time.  You should be able to inspect
config.log to see the actual test that configure ran.

> 
>> Replacement of fdopen, because of
>>   checking whether fdopen sets errno... no
> 
> There was one bug here (failure to set errno when mode string was
> invalid) but I don't think that's the case gnulib was testing for. It
> seems gnulib wants an error for the "may fail" when the fd is invalid.

The 'EBADF may fail' condition is rather weak.  And since glibc
guarantees a definite failure, it is nicer to program to the glibc
interface that guarantees immediate failure on a bad fd at fdopen() time
than it is to deal with the surprises that result when fdopen() succeeds
but later attempts to use the stream fail.  Perhaps it might be worth
splitting this into two gnulib modules, one for the strict POSIX
compliance and one for the glibc interface, but that depends on how
likely people are to want to program to the weaker POSIX interface when
it is just as easy to make fdopen() guarantee failure on bad fds and
save efforts up front.

> 
>> Replacement of futimens, because of
>>   checking whether futimens works... no
> 
> gnulib always forces this test to fail if __linux__ is defined.

That's because the Linux kernel got it wrong for quite some time, and
worse, it was file-system dependent - even if it worked on one machine
and file system, compiling in support for futimens and then running on
another file system would experience random compliance failures due to
the poor file system implementation.

It's been a while, so maybe we can finally graduate this module into
assuming that the Linux kernel is better behaved by default, and make
the user specifically request the fallbacks if they are worried about
using the binary on a file system that still has bugs.  But don't take
it personally - this is not a case of musl getting it wrong, but of the
kernel getting it wrong.

-- 
Eric Blake   eblake@redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org