# Re: strtod ("nan") returns negative NaN

*Date*: Tue, 14 Aug 2018 12:20:56 -0300*From*: Heavenly Avenger <avenger@xxxxxxxxxx>*Subject*: Re: strtod ("nan") returns negative NaN

On 8/14/2018 10:23 AM, Corinna Vinschen wrote:

On Aug 14 21:17, Masamichi Hosoda wrote:On Aug 14 11:56, Corinna Vinschen wrote:On Aug 14 13:45, Masamichi Hosoda wrote:>From a50ee5a4747a99c70469a53fe959f3dc22d3b79a Mon Sep 17 00:00:00 2001 From: Masamichi Hosoda <trueroad@xxxxxxxxxxx> Date: Tue, 14 Aug 2018 12:50:32 +0900 Subject: [PATCH] Fix strtod ("nan") returns qNaN The definition of qNaN for x86_64 and x86 was wrong. So strtod ("nan") returned sNaN instead of qNaN. Furthermore, it was inverted the sign bit with the presence of `-` character. So strtod ("-nan") returned qNaN. This commit fixes definition of qNaN and removes the sign bit inversion when evaluating "nan". --- newlib/libc/stdlib/gd_qnan.h | 8 ++++---- newlib/libc/stdlib/strtod.c | 1 + 2 files changed, 5 insertions(+), 4 deletions(-)[...]With your patch, strtold looks more correct, but it still prints the sign of NaN: strtod ("nan", NULL) = nan strtod ("-nan", NULL) = nan strtold ("nan", NULL) = nan strtold ("-nan", NULL) = -nan nan ("") = nan Question: What's wrong with that? Wouldn't it be more correct if strtod returns -NaN for "-nan" as well?In my investigate, strtold sets sign bit when parameter has '-' character. The wrong long double NaN definition is negative NaN that is set sign bit. So without my patch, both strtold ("nan") and strtold ("-nan") return negative NaN. On the other hand, strtod inverts the sign when parameter has '-' character. The wrong double NaN definition is negative NaN. So without my patch, strtod ("nan") returns negative NaN and strtod ("-nan") returns positive NaN.Your patch improves the situation, that's a sure thing and I did not question that. I just wonder why returning -NaN when the input is "-nan" isn't the better approach. After all: printf ("nan (\"\") = %f\n", nan ("")); printf ("-nan (\"\") = %f\n", -nan ("")); ==> nan ("") = nan -nan ("") = -nan So, shouldn't the ideal outcome be this: strtod ("nan", NULL) = nan strtod ("-nan", NULL) = -nan strtold ("nan", NULL) = nan strtold ("-nan", NULL) = -nan ? Corinna

`I'd say it is not the better/best approach as, even though it makes`

`sense, all other implementations or linux distributions treat it as a`

`plain "nan". So anything written for linux will potentially break on`

`cygwin, I am not sure this is the idea behind cygwin, right?`

`Besides, it only adds complexity when checking for nans, if string`

`comparison is relied upon, as an additional character may show up.`

`As NaN is essentially not a number, what is not a number can't be said`

`as positive or negative. Then we get to a whole philosophical level. It`

`can, but we can't guarantee a cow (which is not a number) can be seen`

`with a "positive cow". A mood (which is not a number), can be seen as`

`positive or negative. Yet it will depend on your concept of a positive`

`or negative mood... so... well, better not leave the algebra sign to`

`this. As 0 is equal to -0. Does -0 exist? :)`

-- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple

**Follow-Ups**:**Re: strtod ("nan") returns negative NaN***From:*Corinna Vinschen

**References**:**Re: strtod ("nan") returns negative NaN***From:*Corinna Vinschen

**Re: strtod ("nan") returns negative NaN***From:*Corinna Vinschen

**Re: strtod ("nan") returns negative NaN***From:*Masamichi Hosoda

**Re: strtod ("nan") returns negative NaN***From:*Corinna Vinschen

- Prev by Date:
**strtod ("nan") returns negative NaN** - Next by Date:
**Re: strtod ("nan") returns negative NaN** - Previous by thread:
**Re: strtod ("nan") returns negative NaN** - Next by thread:
**Re: strtod ("nan") returns negative NaN** - Index(es):