From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1215 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: Wed, 20 Jun 2012 09:27:00 -0400 Message-ID: <20120620132700.GV163@brightrain.aerifal.cx> References: <20120609230541.47eac2de@newbook> <4FD55156.7050302@cs.ucla.edu> <20120611182202.1ee4d019@newbook> <12545931.v3ALTEUUx8@linuix> <20120620030445.GU163@brightrain.aerifal.cx> <4FE14D23.60901@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 1340199077 21969 80.91.229.3 (20 Jun 2012 13:31:17 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 20 Jun 2012 13:31:17 +0000 (UTC) Cc: Isaac Dunham , Paul Eggert , bug-gnulib@gnu.org, Reuben Thomas To: musl@lists.openwall.com Original-X-From: musl-return-1216-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jun 20 15:31:16 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 1ShL03-0001KD-C1 for gllmg-musl@plane.gmane.org; Wed, 20 Jun 2012 15:31:11 +0200 Original-Received: (qmail 8144 invoked by uid 550); 20 Jun 2012 13:31:10 -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 8136 invoked from network); 20 Jun 2012 13:31:09 -0000 Content-Disposition: inline In-Reply-To: <4FE14D23.60901@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:1215 gmane.comp.lib.gnulib.bugs:31076 Archived-At: On Tue, Jun 19, 2012 at 10:10:11PM -0600, Eric Blake wrote: > Unfortunately, you are out of date. POSIX _does_ require > duplocale(LC_GLOBAL_LOCALE) to work: > > http://austingroupbugs.net/view.php?id=301 OK. I'll add support. For now all it requires is avoiding dereferencing the pointer, anyway. > Yes, Linux 2.6.32 introduced F_GETOWN_EX for precisely this reason, and > you should be using it. When I wrote that code, 2.6.32 was new enough, and the issue seemed minor enough, that I didn't bother. Now I agree it would be nice though. > >> test-grantpt.c:34: assertion failed > >> FAIL: test-grantpt > > > > This is an invalid test. POSIX specifies this function "may fail", not > > "shall fail", and since the function is inherently a no-op, it would > > be idiotic to make it perform a syscall to check the validity of the > > file descriptor... > > This is one of the cases where gnulib prefers to emulate the shall fail > semantics of glibc, as they are more useful to program around. I don't see how it's nicer. All it does it make pty acquisition slightly slower (one extra useless syscall). The only time you would call grantpt without knowing that the fd is valid is right after calling posix_openpt without checking the return value, and in that case, it seems unlikely that you'd check the return value of grantpt. And last time I asked, I remember being told that gnulib does not intend to facilitate this sort of lazy programming anyway. In any case, if you are relying on lazy error checking like that, unlockpt will already report the error... > >> test-ptsname_r.c:118: assertion failed > >> FAIL: test-ptsname_r > > > > It's testing that ptsname_r both sets errno and returns the error > > code, and that they're the same. Since this function is nonstandard, > > there's no spec for it, so perhaps this is desirable; I was assuming > > it should return -1 on failure. > > There _is_ a proposed standard for it now: > > http://austingroupbugs.net/view.php?id=508 > > which requires only the return value to be 0 or an errno value, and not > that errno be set. gnulib should only be checking for a valid return value. Okay, I'll update it to match this. I wish they'd just standardized the superior BSD openpty function instead... > >> test-strerror_r.c:118: assertion failed > >> FAIL: test-strerror_r > > > > This test is looking for a null terminator at the n-1 position of the > > buffer if strerror_r fails with ERANGE (buffer too small). I don't see > > anywhere the function is specified to write to the buffer AT ALL on > > failure, so this test seems invalid. > > This is a case where POSIX is rather weak, but where quality of > implementation demands that the most useful interface is one that > provides the most information back to the user. glibc had a number of > bugs that were fixed in this area to improve QoI, and gnulib now prefers > to rely on those improvements. I don't see anything which forbids it from writing in this case, so I suppose I could change it. Rich