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...)?
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
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...)?
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
