mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Eric Blake <eblake@redhat.com>
To: Rich Felker <dalias@aerifal.cx>
Cc: bug-gnulib@gnu.org, Isaac Dunham <idunham@lavabit.com>,
	Paul Eggert <eggert@cs.ucla.edu>,
	musl@lists.openwall.com, Reuben Thomas <rrt@sc3d.org>
Subject: Re: [musl] Re: musl bugs found through gnulib
Date: Mon, 18 Jun 2012 20:07:40 -0600	[thread overview]
Message-ID: <4FDFDEEC.8050304@redhat.com> (raw)
In-Reply-To: <20120619001156.GJ163@brightrain.aerifal.cx>

[-- Attachment #1: Type: text/plain, Size: 2821 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 620 bytes --]

  reply	other threads:[~2012-06-19  2:07 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20120609230541.47eac2de@newbook>
     [not found] ` <4FD55156.7050302@cs.ucla.edu>
     [not found]   ` <20120611182202.1ee4d019@newbook>
2012-06-17 22:49     ` Bruno Haible
2012-06-17 23:54       ` Rich Felker
2012-06-18  8:21         ` Szabolcs Nagy
2012-06-18 13:02           ` John Spencer
2012-06-18 14:55             ` Rich Felker
2012-06-18 15:26               ` Szabolcs Nagy
2012-06-18 16:00                 ` Rich Felker
2012-06-19 13:26               ` John Spencer
2012-06-18  0:16       ` [musl] " idunham
2012-06-19  0:11       ` Rich Felker
2012-06-19  2:07         ` Eric Blake [this message]
2012-06-19  2:52           ` Rich Felker
2012-06-19 11:03             ` musl, fdopen test Bruno Haible
2012-06-19 11:09               ` Jim Meyering
2012-06-20 20:52                 ` Bruno Haible
2012-06-19 10:45         ` musl, printf out-of-memory test Bruno Haible
2012-06-19 19:16           ` Rich Felker
2012-06-19 20:04             ` Bruno Haible
2012-06-19 20:08               ` Rich Felker
2012-06-19 21:17                 ` Bruno Haible
2012-06-20  1:52                   ` Rich Felker
2012-06-20  7:30                     ` Szabolcs Nagy
2012-06-20  9:35                     ` Bruno Haible
2012-06-20 11:00                       ` Jim Meyering
2012-06-21 19:58                         ` Tom Tromey
2012-06-20  3:04       ` Re: musl bugs found through gnulib Rich Felker
2012-06-20  4:10         ` [musl] " Eric Blake
2012-06-20 13:27           ` Rich Felker
2012-06-20  7:32         ` Szabolcs Nagy
2012-06-22 10:39         ` grantpt test Bruno Haible
2012-07-02 22:33         ` [musl] Re: musl bugs found through gnulib Pádraig Brady
2012-06-20 19:28       ` Rich Felker
2012-06-21  2:21         ` Rich Felker
2012-06-21  8:52           ` [musl] " Paul Eggert
2012-06-18  0:05 idunham

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FDFDEEC.8050304@redhat.com \
    --to=eblake@redhat.com \
    --cc=bug-gnulib@gnu.org \
    --cc=dalias@aerifal.cx \
    --cc=eggert@cs.ucla.edu \
    --cc=idunham@lavabit.com \
    --cc=musl@lists.openwall.com \
    --cc=rrt@sc3d.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).