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

On 06/20/2012 05:04 AM, Rich Felker wrote: > Some more updates.. > > On Mon, Jun 18, 2012 at 12:49:44AM +0200, Bruno Haible wrote: >> 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':

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

On 06/20/2012 07:21 PM, Rich Felker wrote: >>> Replacement of mktime, because of >>> checking for working mktime... no > > This test is buggy; it goes into an infinite loop due to integer > overflow UB, because the condition to break out of the loop is only > checked when the test does not fail

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

On Wed, Jun 20, 2012 at 03:28:02PM -0400, Rich Felker wrote: > > Replacement of getcwd, because of > > checking whether getcwd handles long file names properly... no, but it is > > partly working This test is failing because musl uses the kernel to resolve the current directory name, and the ke

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

On Mon, Jun 18, 2012 at 12:49:44AM +0200, Bruno Haible wrote: > [CCing the musl list] > Isaac Dunham wrote in > : > > musl is designed for standards conformance, > > There is a recipe, in

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

On Tue, Jun 19, 2012 at 10:10:11PM -0600, Eric Blake wrote: > Unfortunately, you are out of date. POSIX _does_ require > duplocale(LC_GLOBAL_LOCALE) to work: > > http://austingroupbugs.net/view.php?id=301 OK. I'll add support. For now all it requires is avoiding dereferencing the pointer, anyway

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

On 06/19/2012 09:04 PM, Rich Felker wrote: >> Replacement of duplocale, because of >> checking whether duplocale(LC_GLOBAL_LOCALE) works... no > > POSIX does not specify any use of LC_GLOBAL_LOCALE except as an > argument to uselocale. Is there a reason it's needed? Perhaps more > importantly,

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

Some more updates.. On Mon, Jun 18, 2012 at 12:49:44AM +0200, Bruno Haible wrote: > Replacements of *printf, because of > [...] > checking whether printf survives out-of-memory conditions... no This was caused by the pointer-arithmetic overflow bug I just fixed in git. It should no longer fail,

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

On Mon, Jun 18, 2012 at 08:07:40PM -0600, Eric Blake wrote: > On 06/18/2012 06:11 PM, Rich Felker wrote: > > Some updates... > > > > On Mon, Jun 18, 2012 at 12:49:44AM +0200, Bruno Haible wrote: > >> There is a recipe, in , > >> that explains how to

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

On 06/18/2012 06:11 PM, Rich Felker wrote: > Some updates... > > On Mon, Jun 18, 2012 at 12:49:44AM +0200, Bruno Haible wrote: >> There is a recipe, in , >> that explains how to use gnulib to check a libc against bugs. When I apply >> this to musl-0

Re: [musl] 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 , > 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

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

> [CCing the musl list] > Isaac Dunham wrote in > : >> musl is designed for standards conformance, > > There is a recipe, in , > that explains how to use gnulib to check a libc again

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

> [CCing the musl list] > Isaac Dunham wrote in > : >> musl is designed for standards conformance, > > There is a recipe, in , > that explains how to use gnulib to check a libc again

Re: musl bugs found through gnulib

[CCing the musl list] Isaac Dunham wrote in : > musl is designed for standards conformance, There is a recipe, in , that explains how to use gnulib to check a libc against bugs. Whe