Re: strtod ("nan") returns negative NaN

Corinna Vinschen <[email protected]> Wed, 15 Aug 2018 18:05:44 +0200

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

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...?


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

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