Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120618082100.GT17860@port70.net>
Date: Mon, 18 Jun 2012 10:21:00 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: Re: musl bugs found through gnulib

* Rich Felker <dalias@...ifal.cx> [2012-06-17 19:54:26 -0400]:

> On Mon, Jun 18, 2012 at 12:49:44AM +0200, Bruno Haible wrote:
> > Replacements of *printf, because of
> >   checking whether printf supports infinite 'long double' arguments... no
> 
> I'm just going to change isnanl to handle the invalid bit patterns
> because I'm sick of this issue...
> 

i wonder if these gnulib bugs will get fixed..

gnulib should go over an audit
(otherwise it's not credible considering all
the false tests so far)

some of the gnulib tests will find musl bugs
but many tests are wrong

i think we should not invest too much time
into gnulib but work on a proper libc
testsuit instead..

> > 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
> 
> I'm not sure if it's related, but musl defines PATH_MAX and does not
> attempt to support explicit pathnames longer than PATH_MAX. I'll have
> to look at what the test is doing.
> 

heh it sounds as if gnulib wants getcwd to abort
that's wrong

> > Replacement of perror, because of
> >   checking whether perror matches strerror... no
> 
> Odd, it uses strerror..
> 

this one is musl, in perror.c:
- if (msg) {
+ if (msg && *msg) {

but the gnulib replacement looks dangerous/wrong
(why would you want perror to abort?)

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.