From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1189 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general,gmane.comp.lib.gnulib.bugs Subject: Re: Re: musl bugs found through gnulib Date: Mon, 18 Jun 2012 22:52:32 -0400 Message-ID: <20120619025232.GL163@brightrain.aerifal.cx> References: <20120609230541.47eac2de@newbook> <4FD55156.7050302@cs.ucla.edu> <20120611182202.1ee4d019@newbook> <12545931.v3ALTEUUx8@linuix> <20120619001156.GJ163@brightrain.aerifal.cx> <4FDFDEEC.8050304@redhat.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1340074617 15107 80.91.229.3 (19 Jun 2012 02:56:57 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 19 Jun 2012 02:56:57 +0000 (UTC) Cc: musl@lists.openwall.com, Isaac Dunham , Paul Eggert , bug-gnulib@gnu.org, Reuben Thomas To: Eric Blake Original-X-From: musl-return-1189-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jun 19 04:56:55 2012 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Sgocd-0005Nl-AO for gllmg-musl@plane.gmane.org; Tue, 19 Jun 2012 04:56:51 +0200 Original-Received: (qmail 9785 invoked by uid 550); 19 Jun 2012 02:56:51 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 9777 invoked from network); 19 Jun 2012 02:56:50 -0000 Content-Disposition: inline In-Reply-To: <4FDFDEEC.8050304@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:1189 gmane.comp.lib.gnulib.bugs:31042 Archived-At: 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.. Rich