Re: strtod ("nan") returns negative NaN

Corinna Vinschen <[email protected]> Fri, 17 Aug 2018 11:38:31 +0200

Newsgroups	gmane.comp.lib.newlib
Message-ID	<[email protected]>

On Aug 16 11:56, Corinna Vinschen wrote:
> On Aug 16 10:22, Masamichi Hosoda wrote:
> > > On Aug 15 11:51, Craig Howland wrote:
> > >> On 08/15/2018 11:40 AM, Joseph Myers wrote:
> > >> > On Wed, 15 Aug 2018, Joseph Myers wrote:
> > >> > 
> > >> > > On Tue, 14 Aug 2018, Craig Howland wrote:
> > >> > > 
> > >> > > >       The f_QNAN value should be 0x7fc00000 regardless of byte ordering.  In
> > >> > > It would be better to use __builtin_nan ("") (and __builtin_nanf,
> > >> > > __builtin_nanl for other types) rather than using an integer
> > >> > > representation at all (of course that requires changes to other code to
> > >> > > avoid requiring an integer representation there).
> > >> I totally agree.  To add it to the record, in conjunction with this, the
> > >> strtod implementation really should be upgraded to David Gay's more recent
> > >> version, which is 128-bit friendly.  (I almost had this done some time ago,
> > >> but didn't quite finish.)
> > >> > (This is not an objection to any of the present patch proposals, just an
> > >> > observation that a different approach would avoid a series of problems
> > >> > that result from trying to hardcode information about such choices of
> > >> > bit-patterns for NaNs.)
> > >> > 
> > >> Also agreed.  If I had had time yesterday I might have tried it as I had
> > >> briefly thought of it, but didn't think to get the idea out to the list, so
> > >> I'm glad you did.
> > > 
> > > Sounds like a nice followup patch...?
> > 
> > Here's patch v4.
> > It uses {nan|nanl} ("") instead of the integer representations of NaN.
> > It also removes the unused definitions of them.
> 
> Still looks good on Cygwin.  I'll push this tomorrow, unless somebody
> objects.

Pushed.


Thanks a lot,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

signature.asc (application/pgp-signature, 833 B)