X-Recipient: archive-cygwin AT delorie DOT com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:message-id:to:cc:subject:from:in-reply-to
	:references:mime-version:content-type:content-transfer-encoding;
	 q=dns; s=default; b=a5f7wSi8sz0jOJElzJFQiorRWrOhsMW9AfJaesVS4fc
	/MKtlKweyFBKAMWuNobfMC04nATl1yzJTHxd5cNA4Ysr0qD5y2+VnM/6qSaTWz78
	HLsnhiMNzSVH1F2oh2N7ZRB62+ETuiXzCdn013zh2ePCV8pBghpkOpVfDNCMWuXk
	=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:message-id:to:cc:subject:from:in-reply-to
	:references:mime-version:content-type:content-transfer-encoding;
	 s=default; bh=BR4DVI7x+F1fc5GPg4H/C5win1Y=; b=pnmN3vfFEuzSLZ8/S
	tcF/ZplPtqX6RvEdkn550Fw76KitYZhIsp7inJtg8QBIHa7kjJew4quAww9dL60H
	jzYR7PxQcfVSOYgvLwscPMQ3mcFywc6Gq44UyUdrMxn7y94AQBCWyMIa3D9SOHI2
	r8y5/8enyts2Xys4MuYpyqluy8=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 spammy=H*Ad:D*jp
X-HELO: msc14.plala.or.jp
Date: Wed, 15 Aug 2018 00:54:10 +0900 (JST)
Message-Id: <20180815.005410.1198201163154042143.trueroad@trueroad.jp>
To: cygwin AT cygwin DOT com
Cc: trueroad AT trueroad DOT jp
Subject: Re: strtod ("nan") returns negative NaN
From: Masamichi Hosoda <trueroad AT trueroad DOT jp>
In-Reply-To: <20180814132301.GX3747@calimero.vinschen.de>
References: <20180814 DOT 211757 DOT 2066454831159853501 DOT trueroad AT trueroad DOT jp>	<20180814_dot_211757_dot_2066454831159853501_dot_trueroad_at_trueroad_dot_jp>	<20180814132301 DOT GX3747 AT calimero DOT vinschen DOT de>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-VirusScan: Outbound; mvir-ac14; Wed, 15 Aug 2018 00:54:15 +0900

[...]
>> > 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
> 
> ?

On Linux,
strtof ("nan"), strtof ("-nan"),
strtod ("nan"), strtod ("-nan"),
strtold ("nan"), and strtold ("-nan")
all return positive NaN.

My patch is for closing to the behavior of Linux.
I don't know why Linux's strtod ("-nan") does not return negative NaN.
But, probably because both positive and negative NaN behave in the same way,
I think.

Here's sample code.
```
#include <math.h>
#include <stdio.h>
#include <stdlib.h>

int main (void)
{
  double pnan = nan ("");
  double nnan = -pnan;

  printf ("positive NaN == positive NaN: ");
  if (pnan == pnan)
    printf ("true\n");
  else
    printf ("false\n");

  printf ("negative NaN == negative NaN: ");
  if (nnan == nnan)
    printf ("true\n");
  else
    printf ("false\n");

  printf ("0 < positive NaN: ");
  if (0 < pnan)
    printf ("true\n");
  else
    printf ("false\n");

  printf ("0 > positive NaN: ");
  if (0 > pnan)
    printf ("true\n");
  else
    printf ("false\n");

  printf ("0 < negative NaN: ");
  if (0 < nnan)
    printf ("true\n");
  else
    printf ("false\n");

  printf ("0 > negative NaN: ");
  if (0 > nnan)
    printf ("true\n");
  else
    printf ("false\n");
}
```

Result:
```
positive NaN == positive NaN: false
negative NaN == negative NaN: false
0 < positive NaN: false
0 > positive NaN: false
0 < negative NaN: false
0 > negative NaN: false
```

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