Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 25 Dec 2014 09:53:49 -0500
From:      Pedro Giffuni <pfg@freebsd.org>
To:        Bruce Evans <brde@optusnet.com.au>
Cc:        freebsd-standards@freebsd.org
Subject:   Re: Does posix say anything about the sign in NaNs ?
Message-ID:  <003E7D36-61E0-4572-A98C-24351F6ADF5A@freebsd.org>
In-Reply-To: <20141225235228.H927@besplex.bde.org>
References:  <549B1115.8000909@FreeBSD.org> <20141225235228.H927@besplex.bde.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Hello;

> Il giorno 25/dic/2014, alle ore 09:00, Bruce Evans =
<brde@optusnet.com.au> ha scritto:
>=20
> On Wed, 24 Dec 2014, Pedro Giffuni wrote:
>=20
>> I got the attached patch from OpenBSD.
>>=20
>> It says:
>> ____
>> Show the sign for NaN as per POSIX; from Elliott Hughes.
>> ok martynas@, millert@, doug@
>> ____
>>=20
>> I can't find a reference in POSIX documentation to support it though.
>=20
> The behaviour is implementation-defined.  =46rom n869.txt for printf:
>=20
> X                A  double  argument  representing  an  infinity   is
> X                converted in one of the styles [-]inf or [-]infinity
> X                 --   which  style  is  implementation-defined.    A
> X                double  argument  representing a NaN is converted in
> X                one of the styles [-]nan or [-]nan(n-char-sequence)
> X                 --  which style, and the  meaning  of  any  n-char-
> X                sequence,    is   implementation-defined.    The   F
> X                conversion specifier produces INF, INFINITY, or  NAN
> X                instead of inf, infinity, or nan, respectively.220)
>=20
> "style" is not clearly defined.  The format for input in strtod()
> is formally defined as [-]something without using the term "style",
> but the specication for actually handling the minus sign is even less
> complete (see below).
>=20
> The library intentionally suppresses the sign for NaNs on output.
> This is consistent with it ignororing the sign for NaNs on input.
>=20


Interesting and pretty much the reason why I wanted to discuss the =
change.

I can see the sign information is important for infinity but indeed it =
makes
very little sense (if any) for NaN. OTOH, we are doing an extra =
assignment
to hide something the standard permits. If we are ignoring the sign of =
NaNs
on input there should be no such sign information in the first place and
ignoring the value is unnecessary.

While I am tempted to follow the change, I think it is pretty much =
innocuous
as no reasonably correct program should depend on the sign of NaN.

Pedro.




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?003E7D36-61E0-4572-A98C-24351F6ADF5A>