Re: strtod ("nan") returns negative NaN

Corinna Vinschen <[email protected]>
Newsgroups gmane.comp.lib.newlib
Message-ID <[email protected]>
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.


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat
signature.asc (application/pgp-signature, 833 B)
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAlt1SkUACgkQ9TYGna5E
T6BSiA//bcw/CYltOb1KvQOWCKxfSoF4SjFHzJPjx2YzmGL+SsHrur/qxIhLOvcH
34peNSS1OcQiTbOYpkRa3wtOjsq4Ej3jELUhCcdkoPXeDHvyvk8d2T1A7tcRShAy
5UizYN5HJJErwHXgMyAkiU52Bn5BANL3ga3PtVgZCSwwNeoNAvoJhPr3D8RkH1wm
hjZcTbmc/mHa2P1rIsP75pIlI5CdaNtOjcLd876zuyHpRRMt7CAzh8vrFn80yyMA
vcvYKd8itHwr7Rf5U8d3+iImfhR9jNlaYJSdx1Jsew+3l4e2zcKoWY86APShDH3N
EXpGLOtpik+Q546pXry7m5oZ1I7ojUPpynruN3Ltf8i/Ym6gvEvL4fTC/KtwoKO9
ZlFjFQbrYulrkelxtbZgeDXNMmlBdiUzdad5iv9gYX6w4lOQlysHfOFYGJH0zZQp
37rtxzHUyXxtQ0W0SqlUd7Emn0X8QVshnxL9IMDxjFL+gy9xTDClOJwWgmTCDl3p
MDVFqEm6JW/oMdp5Khv7yNG4ijht5XqqUTuSgTKGhKVCIw1vr7XxE2kiksE0OIqT
9jbytZB2DgDMnZMNRfNpjsib4V6XOZvnbaBzEGugXGJxdZFdP/mg0PbQDmphTNFp
Gb97LqrGZmWaNzrh/7S7zNN/H4NKvOyCgXfKHBpVBNr770WlLIo=
=Hbmr
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.