From nobody@FreeBSD.org  Wed Feb 28 18:02:05 2007
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 4A2DE16A407
	for <freebsd-gnats-submit@FreeBSD.org>; Wed, 28 Feb 2007 18:02:05 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [69.147.83.33])
	by mx1.freebsd.org (Postfix) with ESMTP id 2C72213C4A5
	for <freebsd-gnats-submit@FreeBSD.org>; Wed, 28 Feb 2007 18:02:05 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.13.1/8.13.1) with ESMTP id l1SI247A005333
	for <freebsd-gnats-submit@FreeBSD.org>; Wed, 28 Feb 2007 18:02:04 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.13.1/8.13.1/Submit) id l1SI24Cb005332;
	Wed, 28 Feb 2007 18:02:04 GMT
	(envelope-from nobody)
Message-Id: <200702281802.l1SI24Cb005332@www.freebsd.org>
Date: Wed, 28 Feb 2007 18:02:04 GMT
From: Denis Koreshkov<dynamic-wind@mail.ru>
To: freebsd-gnats-submit@FreeBSD.org
Subject: printing -NaN
X-Send-Pr-Version: www-3.0

>Number:         109692
>Category:       kern
>Synopsis:       [libc] printing -NaN
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Feb 28 18:10:03 GMT 2007
>Closed-Date:    Mon Jan 28 06:04:22 UTC 2008
>Last-Modified:  Mon Jan 28 06:04:22 UTC 2008
>Originator:     Denis Koreshkov
>Release:        freebsd 6.2-stable
>Organization:
BMSTU
>Environment:
>Description:

The vfprintf() function correctly formats +Inf and -Inf but it has no
provision for distinguishing between +NaN and -NaN. Hence all functions
of printf(3) family output all -NaNs as NaNs.
>How-To-Repeat:

printf("%g %g\n", +0.0/0.0, -0.0/0.0);

outputs: NaN NaN
which should be: NaN -NaN

>Fix:

vfprintf(3) tests for a 'double' argument being an Inf or a NaN using
isinf() and isinf().

Then, an Inf's signum is detected by a trivial arithmetic comparison to 0.0
But arithmetic comparisons fail when an argument is a NaN, so there is no
corresponding code to set a negative NaN's signum  to '-'.

Consider using copysign(1.0, _double) which returns +1.0 and -1.0 for
+NaN and -NaN. This is the case for the msun libm used in FreeBSD,
though other implementations of copysign(3) may not derive a NaN's
signum correctly, or raise an exception with signaling NaNs.
>Release-Note:
>Audit-Trail:

From: David Schultz <das@FreeBSD.ORG>
To: Denis Koreshkov <dynamic-wind@mail.ru>
Cc: freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: bin/109692: printing -NaN
Date: Thu, 10 Jan 2008 00:46:37 -0500

 On Wed, Feb 28, 2007, Denis Koreshkov wrote:
 > The vfprintf() function correctly formats +Inf and -Inf but it
 > has no provision for distinguishing between +NaN and -NaN. Hence
 > all functions of printf(3) family output all -NaNs as NaNs.
 
 Thanks for pointing this out. I believe that this is historical
 and deliberate behavior, and I do not think it violates C99 or
 IEEE P754. To quote from IEEE P754:
 
    Conversion of a quiet NaN in a supported format to an external
    character sequence shall produce a language-defined one of
    "nan" or a sequence that is equivalent except for case (e.g.,
    "NaN"), with an optional preceding sign. The sign of a NaN has
    no meaning. (5.12.1)
 
 In an abstract sense, NaNs aren't signed; none of the usual
 mathematical operators can be used to distinguish a "positive NaN"
 from a "negative NaN", even though the underlying representation
 includes a sign bit. Only operations that operate directly on the
 bit strings (IEEE P754 defines assignment, negation, fabs, and
 copysign) have a well-defined effect on the sign bit. For all
 other operations, the hardware is granted free license to set the
 sign bit of a NaN however it wants (6.3). Thus, printing the sign
 for NaNs would probably reduce portability, not to mention
 violating POLA.
State-Changed-From-To: open->closed 
State-Changed-By: das 
State-Changed-When: Mon Jan 28 06:02:55 UTC 2008 
State-Changed-Why:  
The present behavior is believed to be correct, and the submitter 
has not replied with an objection. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=109692 
>Unformatted:
