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 ebl...@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature