Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 18 Jun 2012 22:52:32 -0400
From: Rich Felker <>
To: Eric Blake <>
Cc:, Isaac Dunham <>,
	Paul Eggert <>,,
	Reuben Thomas <>
Subject: Re: Re: musl bugs found through gnulib

On Mon, Jun 18, 2012 at 08:07:40PM -0600, Eric Blake wrote:
> 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 <>,
> >> 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.

OK, then no idea what's causing this. I was going to try running the
test but I didn't have autotools installed on the system I wanted to
test on, so I put it off..

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

The only real-world situation I can think of where you'd care that
fdopen detect EBADF is when you've just called a function that
allocates the file descriptor and directly passed it to fdopen without
first checking the return value. For instance:

FILE *f = fdopen(open(pathname, O_RDWR|O_CLOEXEC), "rb+");

instead of:

int fd = open(pathname, O_RDWR|O_CLOEXEC);
if (fd<0) goto error;
FILE *f = fdopen(fd, "rb+");

The former is rather lazy programming, but maybe gnulib intends to
support this kind of programming.

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

My thought in having musl skip the test is to maximize performance of
fdopen, assuming you might be using it in a situation like on a newly
accept()ed network connection where every syscall counts (think
multi-threaded httpd). For read-only fdopen, no syscalls are needed,
but if writing is possible, fdopen has to make a syscall to check
whether the fd is a tty in order to decide whether to enable line
buffering or full buffering, and in principle it could detect EBADF at
the same time for no cost.

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

Yes, it might be nice if the test output made it clear that it was
hard-coded to fail so nobody goes looking for nonexistant bugs..


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.