Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 8 Jun 2012 11:29:35 -0400
From: Rich Felker <>
Subject: Re: printf POSIX compliance

On Fri, Jun 08, 2012 at 05:06:18PM +0200, Szabolcs Nagy wrote:
> * Rich Felker <> [2012-06-08 10:55:19 -0400]:
> > On Fri, Jun 08, 2012 at 10:44:23AM -0400, Rich Felker wrote:
> > > Still working on finding whether this long double issue is what's
> > > causign the gnulib junk to get pulled in...
> > 
> > And it's not, at least not in the worst package, GNU m4. I #if'd out
> > the broken long double test in configure, re-ran it, and even with no
> > printf problems reported, freadahead is still getting pulled in...
> > I'll see if I see anything else odd.
> > 
> i've just checked m4 and it uses freadseek and closein
> both functions are from gnulib and depend on freadahead
> so m4 will use freadahead independently of the printf issue

Thanks; I think that settles it then. I wonder if they'd accept a
patch upstream to fix this bug..

I've just fixed a few minor issues found by the autoconf/gnulib tests:

- strtod("-0x",0) returning positive zero when it should return
  negative zero.
- stdint.h applying wrong signedness in some of the const macros.

I've also found a couple more invalid tests in gnulib/autoconf:

- The getopt test for "POSIX compatible" getopt is backwards; it
  actually tests for POSIX-incompatible GNU semantics.
- isnanl is checking behavior on invalid ld80 representations, just
  like the printf test.

And one valid test that fails:

- The strtod test is attempting to convert "nan()". This is required
  to be accepted and yield a NAN, even though the interpretation of
  the contents of the () is implementation-defined. I'll add support
  for this later.


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.