The GNUlib portability library bug discussion list

idunham | 18 Jun 2012 02:05

Re: [musl] Re: musl bugs found through gnulib

> [CCing the musl list]
> Isaac Dunham wrote in
> <http://lists.gnu.org/archive/html/bug-gnulib/2012-06/msg00101.html>:
>> musl is designed for standards conformance,
>
> There is a recipe, in <http://sourceware.org/glibc/wiki/Testing/Gnulib>,
> that explains how to use gnulib to check a libc against bugs.
Be warned: a bad test can cause failures as well.
It's been one of the musl developers' complaints about gnulib that the
tests are buggy and frequently check for glibc behavior instead of
standard behavior.
> When I apply this to musl-0.9.1, I get this list of problems:
>
> Replacements of *printf, because of
>   checking whether printf supports infinite 'long double' arguments... no
>   checking whether printf supports the 'ls' directive... no
>   checking whether printf survives out-of-memory conditions... no
At least one of these (infinite long double, IIRC) is invalid or a test
for a GNU-ism. This was previously discussed on the musl ML. OOM behavior
is undefined AFAICT (feel free to point out a standard), and the scenario
is a lot less likely with musl than glibc for several reasons.

> Replacement of duplocale, because of
>   checking whether duplocale(LC_GLOBAL_LOCALE) works... no
Need to check this one
> Replacement of fdopen, because of
>   checking whether fdopen sets errno... no
I presume this is nonconformance to POSIX ("otherwise, a null pointer
shall be returned and errno set...")?

(Continue reading)

headers

Rich Felker | 18 Jun 2012 02:29

Re: Re: musl bugs found through gnulib

On Sun, Jun 17, 2012 at 05:05:23PM -0700, idunham <at> lavabit.com wrote:
> > Replacement of fdopen, because of
> >   checking whether fdopen sets errno... no
> I presume this is nonconformance to POSIX ("otherwise, a null pointer
> shall be returned and errno set...")?

The EBADF error is a "may fail", not a "shall fail", per POSIX. Since
it requires an extra syscall in the general case (although in some
special cases, we're already making a syscall that could detect
EBADF), I find it's probably just an undesirable performance hit.
Applications should interpret the "may fail" as meaning it's not
valid/portable to call fdopen with an invalid file descriptor and
assume you can get a FILE* that will generate EBADF when it's used
later, not as meaning that the implementation will do their
error-checking for them.

> > Replacement of futimens, because of
> >   checking whether futimens works... no
> Could be a bug.

See the #ifdef __linux__ in the test file. Due to old buggy kernels,
they ALWAYS consider futimens broken on Linux.

> > Replacement of getcwd, because of
> >   checking whether getcwd handles long file names properly... no, but it
> > is partly working
> Is this a test for ERANGE handling (error on name >= size)? Other than
> that, I see no specification covering this.
> >   checking whether getcwd aborts when 4k < cwd_length < 16k... no
> AFAICT, only required to error when size =< cwd_length. If size !<

(Continue reading)