Date: Mon, 18 Jun 2012 22:52:32 -0400 From: Rich Felker <dalias@...ifal.cx> To: Eric Blake <eblake@...hat.com> Cc: musl@...ts.openwall.com, Isaac Dunham <idunham@...abit.com>, Paul Eggert <eggert@...ucla.edu>, bug-gnulib@....org, Reuben Thomas <rrt@...d.org> 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 <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. 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.. Rich
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.