[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <54705.50.0.229.11.1339977923.squirrel@lavabit.com>
Date: Sun, 17 Jun 2012 17:05:23 -0700 (PDT)
From: idunham@...abit.com
To: musl@...ts.openwall.com
Cc: bug-gnulib@....org,
"Isaac Dunham" <idunham@...abit.com>,
"Paul Eggert" <eggert@...ucla.edu>,
"Reuben Thomas" <rrt@...d.org>
Subject: Re: 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...")?
> Replacement of futimens, because of
> checking whether futimens works... no
Could be a bug.
> 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 !<
(cwd_length + 1), that is conformant behavior. (See man 3posix getcwd)
> Replacement of getopt, because of
> checking whether getopt is POSIX compatible... no
We'd need to see this test...(will look later).
> Replacement of glob, because of
> checking for GNU glob interface version 1... no
> (not sure this is a bug or just an incompatibility compared to glibc)
Looks like an incompatability, since it specifies "GNU interface"...
> Replacement of iconv and iconv_open, because of
> checking whether iconv supports conversion between UTF-8 and
> UTF-{16,32}{BE,LE}... no
Not "nonconformant" from the standpoint of POSIX, AFAICT, but it is
incomplete. musl is UTF8 native, but I don't think it supports UTF16/UTF32
yet.
> Replacement of mktime, because of
> checking for working mktime... no
> Replacement of perror, because of
> checking whether perror matches strerror... no
> Replacement of popen, because of
> checking whether popen works with closed stdin... no
Look like bugs, if the description is correct.
> Replacement of regex, because of
> checking for working re_compile_pattern... no
This is #ifdef __USE_GNU
I'm not aware of any standard covering GNU APIs...
> Replacement of strtod, because of
> checking whether strtod obeys C99... no
>
> For each of the replacements, first look at the test program's results
> (in config.log), then look at the test program's source code (in m4/*.m4).
>
Thanks,
Isaac Dunham
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.
