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