Re: strtod ("nan") returns negative NaN
Corinna Vinschen <[email protected]>
| Newsgroups | gmane.comp.lib.newlib |
|---|---|
| Message-ID | <[email protected]> |
On Aug 15 15:29, Masamichi Hosoda wrote:
> > On 08/14/2018 08:02 PM, Masamichi Hosoda wrote:
> >>> On Wed, 15 Aug 2018, Masamichi Hosoda wrote:
> >>>
> >>>> On Linux with glibc, both strtod ("nan")
> >>>> and strtod ("-nan") return positive NaN.
> >>>>
> >>>> So I've created the patch that behaves like glibc.
> >>>> Both strtod ("nan") and strtod ("-nan") return positive NaN.
> >>> I would suggest that you should not consider fixed bugs in glibc (bug
> >>> 23007 in this case) to be appropriate to emulate in other libraries.
> >> I've create the patch that behaves to preserve the sign bit.
> >>
> >> The result on Cygwin 64 bit (newlib, x86_64) with the patch:
> >> ```
> >> strtof ("nan", NULL) = nan
> >> strtof ("-nan", NULL) = -nan
> >> strtod ("nan", NULL) = nan
> >> strtod ("-nan", NULL) = -nan
> >> strtold ("nan", NULL) = nan
> >> strtold ("-nan", NULL) = -nan
> >> ```
> >>
> >> Thank you for your suggestion.
> > The f_QNAN value should be 0x7fc00000 regardless of byte
> > ordering. In addition, the d_QNAN* values should be 0x0 and
> > 0x7FF80000, with only the index changing based on byte ordering. So
> > instead of them being inside of a x86/x86_64 define, they should just
> > have their values corrected in the LITTLE_ENDIAN clause.
> > x86 does use a different coding for their 80-bit long double, so
> > the ldus_QNAN* defines could belong within an x86 define. On the
> > other hand, the ldus_QNAN* defines only apply for Intel 80-bit, so in
> > that respect don't need to be within a guard.
> > The ld_QNAN defines are not actually used anywhere. If they
> > were, however, Intel 80-bit would require different values than
> > 128-bit. However, the long double support in Newlib really only works
> > when long double is the same size as double. Some functions can work
> > with Intel 80-bit, but almost none of them work with 128-bit.
> > Given the prior considerations, I suggest that only the values
> > get fixed so that Cygwin works, but the #if x86 is not added. For
> > this to work on other platforms (128-bit long double), more work will
> > be needed. Again, sorry that I can't provide a git diff patch, but
> > here's a suggested one with diff -pu. It contains the value
> > corrections from Masamichi, but skips the #if x86 and adds a comments
> > about some of the deficiencies.
> > The changes to strtod.c look OK.
>
> Thank you for your suggestion.
> Here's patch v3.
Looks good on Cygwin. Everybody ok with this patch?
Thanks,
Corinna
--
Corinna Vinschen
Cygwin Maintainer
Red Hat
signature.asc
(application/pgp-signature, 833 B)
-----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAltz7VMACgkQ9TYGna5E T6DD2A/5ATfZKifQzHnIOEU4u8nipz8yM17YlaNMGxBUGUJLYsPbakFP9li+kibg Qo2D/y4qgCBIj+MKnjDHVbIPQkqYM3mJaLKQCx4Eqp1APnApG+hIZUDxP9ftLfIt jQXC1ld+UGN1zarTSaMZZppgtFrQzx9Q/FhbC7ujxGKEQNf/hyTyj7wkxJUDKqF7 EQFKeLTvE4KD0TBWhsEN2ZBtC8I2AaXypGdPtHK/9PIJAFqpkFji46o4xBvGIAur XU/YLI5TNZYG2k2Jnk9nkKhsfMBtr/sl4PLRqxOmn9cIYnSdGJt4YIWgiO2EhqmM xbHuB+oZWTgMK0yulR6hNwfirKu2Ow22fONc6mUj+W3A7yLF5cYNzFsnCXqV4ZBq Aqabr/1dK6WvrxfhTy5zYamHxX19JmDqtAehIzTontA9JnU9w0f6pia4IjwuU+T+ c3cQInIJ4MV0Ls4NVIijxxt5a38sFY+z4rfsYWODM7Qmw7/qr9BGvvaaDAHa9UhX HBiGZQGNwcPdYw7mjCLr0qe4a3jmTy4Df0xqy5yI2SR7eDrBl7eTzhQaTJY1Tc1P 0VD2gYtwiy9ueGT2l/ZcuKFlWq59uOqgoBOxkLA5zDiVJDhU99Pgdqn4SxaJktMO QDb1cWO51+OZI5Nso9jC+mPjYl7WL3V3P0WXe6a3FKFV+ZL6+C8= =ElZL -----END PGP SIGNATURE-----