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