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:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=XUwUg1cDFO8xHp32
	wckvOBFD4t9SEhVjtESTNOWUJ7oVVVuavqraei+Xuo7ao9XNOilc8YeIzVVTikNC
	cj9CUNigKiuBlzutBn5I2E59DY51mDO8j3rqwyGOh6OdpLAxWu/4jfcgbLT8tYau
	uwJNAH8wFiZlvYreOHYh3F16zb0=
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:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; s=default; bh=2xFq9hxW5NTR2iuMYxYs77
	wp+zo=; b=fp74mJ/qcsC/EqADRcVeQVUNTU3X6x6ehXdF6ZhmE9/GuHHYMsFHYo
	AtQSUW5ZzuwC9EtVP4Ds9VTe540mfT64+L/46OwOpzPg5Ho33LRgfORcsG4mUwUo
	2EzWkcRT6Zbr1uWnDz4JKmKyRuuVQmG2pxDad+NcI+46Go8FUQDZU=
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=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=international, International
X-HELO:	mx1.redhat.com
Subject:	Re: strtod ("nan") returns negative NaN
To:	cygwin AT cygwin DOT com
References:	<20180814132301 DOT GX3747 AT calimero DOT vinschen DOT de> <5b730d82 DOT 1c69fb81 DOT f063b DOT d706 AT mx DOT google DOT com> <8636vgac6e DOT fsf AT gmail DOT com> <CANnLRdiv6KsEz3bQz54aL5Oxfytv=GUXxL3=MZ+4YZ75O7tTHQ AT mail DOT gmail DOT com>
From:	Eric Blake <eblake AT redhat DOT com>
Message-ID:	<06e75f75-6a5f-2140-7557-849290225f79@redhat.com>
Date:	Tue, 14 Aug 2018 16:44:59 -0500
User-Agent:	Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version:	1.0
In-Reply-To:	<CANnLRdiv6KsEz3bQz54aL5Oxfytv=GUXxL3=MZ+4YZ75O7tTHQ@mail.gmail.com>
X-IsSubscribed:	yes

On 08/14/2018 04:31 PM, Stephen John Smoogen wrote:

>> The C standard disagrees with you [ISO:IEC 9899:2011, section 5.2.4.2.2]:
>>
>> "An implementation may give zero and values that are not floating-point
>> numbers (such as infinities and NaNs) a sign or may leave them unsigned.
>> Wherever such values are unsigned, any requirement in this International
>> Standard to retrieve the sign shall produce an unspecified sign, and any
>> requirement to set the sign shall be ignored."
>>
> 
> Does it disagree? I would say it did if it said MUST.. but it says MAY
> I thought usually meant "be consistent with what you think is right
> for your environment but yeah whatever".

Read conversely, if the implementation lets NaN have a sign (which 
Cygwin does), then retrieving and setting the sign is defined.

> 
>   And one can read the "any requirement to set the sign shall be
> ignored" as being -NaN should come back as NaN. I don't know how this
> is also affected by https://en.wikipedia.org/wiki/ISO/IEC_10967 which
> goes to the IEEE 754 NaN is not a number (except when it is). [
> 
> It looks from my layman point of view that Cygwin is ok with sending
> whatever they want back if it is implementation defined. However the
> bigger case is whether they want to be similar to how the other
> environments report things. Currently Cygwin reports -NaN for positive
> NaN and 'NaN' for '-NaN'.. which may be ok but doesn't match the other
> environments which all report NaN. [Does that make sense?]

Cygwin is indeed buggy for turning "NaN" into -NaN; that's easy enough 
to fix. The remaining question is whether it should turn "-NaN" into 
-NaN; and the argument that glibc JUST fixed their bug 23007 to make 
strtod("-nan") return -NaN means that Cygwin should, indeed, preserve 
the negative sign bit when parsing "-nan".

https://sourceware.org/bugzilla/show_bug.cgi?id=23007

So, the desired behavior:

strtod("nan") -> NaN
strtod("-nan") -> -NaN
printf("%f", NaN) -> "NaN"
printf("%f", -NaN) -> "-NaN"

and similarly for float and long double.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

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

- Raw text -