[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120619001156.GJ163@brightrain.aerifal.cx>
Date: Mon, 18 Jun 2012 20:11:56 -0400
From: Rich Felker <dalias@...ifal.cx>
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
Some updates...
On Mon, Jun 18, 2012 at 12:49:44AM +0200, Bruno Haible wrote:
> 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 survives out-of-memory conditions... no
No idea. Copying out the test and running it directly, it passes just
fine for me. Maybe gnulib has already replaced printf with its own
malloc-using version by the time it gets to this test??
> Replacement of fdopen, because of
> checking whether fdopen sets errno... no
There was one bug here (failure to set errno when mode string was
invalid) but I don't think that's the case gnulib was testing for. It
seems gnulib wants an error for the "may fail" when the fd is invalid.
> Replacement of futimens, because of
> checking whether futimens works... no
gnulib always forces this test to fail if __linux__ is defined.
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.
