From: Rich Felker <dalias@aerifal.cx>
To: musl@lists.openwall.com
Cc: bug-gnulib@gnu.org, Isaac Dunham <idunham@lavabit.com>,
Paul Eggert <eggert@cs.ucla.edu>, Reuben Thomas <rrt@sc3d.org>
Subject: Re: Re: musl bugs found through gnulib
Date: Wed, 20 Jun 2012 15:28:02 -0400 [thread overview]
Message-ID: <20120620192802.GW163@brightrain.aerifal.cx> (raw)
In-Reply-To: <12545931.v3ALTEUUx8@linuix>
On Mon, Jun 18, 2012 at 12:49:44AM +0200, Bruno Haible wrote:
> [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. 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
Fixed. (Not really a bug, but fixed anyway.)
> checking whether printf supports the 'ls' directive... no
Previously fixed.
> checking whether printf survives out-of-memory conditions... no
Fixed.
> Replacement of duplocale, because of
> checking whether duplocale(LC_GLOBAL_LOCALE) works... no
Fixed.
> Replacement of fdopen, because of
> checking whether fdopen sets errno... no
Not a bug. I believe this was fixed in gnulib.
> Replacement of futimens, because of
> checking whether futimens works... no
Not a bug; just confusing message.
> Replacement of getcwd, because of
> checking whether getcwd handles long file names properly... no, but it is partly working
> checking whether getcwd aborts when 4k < cwd_length < 16k... no
Still open; probably not a bug.
> Replacement of getopt, because of
> checking whether getopt is POSIX compatible... no
Not a bug.
> 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)
Not supported.
> Replacement of iconv and iconv_open, because of
> checking whether iconv supports conversion between UTF-8 and UTF-{16,32}{BE,LE}... no
Fixed.
>
> Replacement of mktime, because of
> checking for working mktime... no
Still open.
> Replacement of perror, because of
> checking whether perror matches strerror... no
Fixed.
> Replacement of popen, because of
> checking whether popen works with closed stdin... no
Fixed.
> Replacement of regex, because of
> checking for working re_compile_pattern... no
Not supported.
> Replacement of strtod, because of
> checking whether strtod obeys C99... no
Previously fixed.
> test-duplocale.c:70: assertion failed
> FAIL: test-duplocale
Fixed.
> test-fcntl.c:382: assertion failed
> FAIL: test-fcntl
Pending; intend to fix.
> test-fdatasync.c:50: assertion failed
> FAIL: test-fdatasync
Fixed.
> test-fma2.h:116: assertion failed
> FAIL: test-fma2
Unknown. Asking nsz..
> test-fsync.c:50: assertion failed
> FAIL: test-fsync
Fixed.
> test-fwrite.c:53: assertion failed
> FAIL: test-fwrite
Fixed.
> test-getlogin_r.c:88: assertion failed
> FAIL: test-getlogin_r
Fixed.
> test-grantpt.c:34: assertion failed
> FAIL: test-grantpt
Buggy/useless test.
> test-localeconv.c:41: assertion failed
> FAIL: test-localeconv
Fixed.
> Segmentation fault
> FAIL: test-localename
Still open.
> test-ptsname_r.c:118: assertion failed
> FAIL: test-ptsname_r
Fixed.
> test-strerror_r.c:118: assertion failed
> FAIL: test-strerror_r
Fixed.
> test-wcwidth.c:71: assertion failed
> FAIL: test-wcwidth
Fixed.
> When I compile all of gnulib, I also get a compilation error
> (may be a musl or a gnulib problem, haven't investigated):
> fsusage.c: In function 'get_fs_usage':
> fsusage.c:222:17: error: storage size of 'fsd' isn't known
> fsusage.c:224:3: warning: implicit declaration of function 'statfs' [-Wimplicit-function-declaration]
> fsusage.c:222:17: warning: unused variable 'fsd' [-Wunused-variable]
> make[4]: *** [fsusage.o] Error 1
OK, this is valid fallback code for when statvfs fails, but the
headers required for it have not been included.
Basically the only still-open issues are getcwd, mktime, fma,
localename, so I'll avoid future spam by just addressing them. I've
kept all the Cc's so far, but if this is getting OT for gnulib folks,
I'll be happy to drop the Cc. Just let me know.
Rich
next prev parent reply other threads:[~2012-06-20 19:28 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20120609230541.47eac2de@newbook>
[not found] ` <4FD55156.7050302@cs.ucla.edu>
[not found] ` <20120611182202.1ee4d019@newbook>
2012-06-17 22:49 ` Bruno Haible
2012-06-17 23:54 ` Rich Felker
2012-06-18 8:21 ` Szabolcs Nagy
2012-06-18 13:02 ` John Spencer
2012-06-18 14:55 ` Rich Felker
2012-06-18 15:26 ` Szabolcs Nagy
2012-06-18 16:00 ` Rich Felker
2012-06-19 13:26 ` John Spencer
2012-06-18 0:16 ` [musl] " idunham
2012-06-19 0:11 ` Rich Felker
2012-06-19 2:07 ` [musl] " Eric Blake
2012-06-19 2:52 ` Rich Felker
2012-06-19 11:03 ` musl, fdopen test Bruno Haible
2012-06-19 11:09 ` Jim Meyering
2012-06-20 20:52 ` Bruno Haible
2012-06-19 10:45 ` musl, printf out-of-memory test Bruno Haible
2012-06-19 19:16 ` Rich Felker
2012-06-19 20:04 ` Bruno Haible
2012-06-19 20:08 ` Rich Felker
2012-06-19 21:17 ` Bruno Haible
2012-06-20 1:52 ` Rich Felker
2012-06-20 7:30 ` Szabolcs Nagy
2012-06-20 9:35 ` Bruno Haible
2012-06-20 11:00 ` Jim Meyering
2012-06-21 19:58 ` Tom Tromey
2012-06-20 3:04 ` Re: musl bugs found through gnulib Rich Felker
2012-06-20 4:10 ` [musl] " Eric Blake
2012-06-20 13:27 ` Rich Felker
2012-06-20 7:32 ` Szabolcs Nagy
2012-06-22 10:39 ` grantpt test Bruno Haible
2012-07-02 22:33 ` [musl] Re: musl bugs found through gnulib Pádraig Brady
2012-06-20 19:28 ` Rich Felker [this message]
2012-06-21 2:21 ` Rich Felker
2012-06-21 8:52 ` [musl] " Paul Eggert
2012-06-18 0:05 idunham
2012-06-18 0:29 ` Rich Felker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120620192802.GW163@brightrain.aerifal.cx \
--to=dalias@aerifal.cx \
--cc=bug-gnulib@gnu.org \
--cc=eggert@cs.ucla.edu \
--cc=idunham@lavabit.com \
--cc=musl@lists.openwall.com \
--cc=rrt@sc3d.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).