Date: Thu, 10 Jan 2008 05:50:02 GMT From: David Schultz <das@FreeBSD.org> To: freebsd-bugs@FreeBSD.org Subject: Re: bin/109692: printing -NaN Message-ID: <200801100550.m0A5o269045143@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/109692; it has been noted by GNATS.
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200801100550.m0A5o269045143>