[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120620132700.GV163@brightrain.aerifal.cx>
Date: Wed, 20 Jun 2012 09:27:00 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Cc: 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 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
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.
