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>
index | next in thread | previous in thread | raw e-mail
Hello; > Il giorno 25/dic/2014, alle ore 09:00, Bruce Evans <brde@optusnet.com.au> ha scritto: > > On Wed, 24 Dec 2014, Pedro Giffuni wrote: > >> I got the attached patch from OpenBSD. >> >> It says: >> ____ >> Show the sign for NaN as per POSIX; from Elliott Hughes. >> ok martynas@, millert@, doug@ >> ____ >> >> I can't find a reference in POSIX documentation to support it though. > > The behaviour is implementation-defined. From n869.txt for printf: > > 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) > > "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). > > The library intentionally suppresses the sign for NaNs on output. > This is consistent with it ignororing the sign for NaNs on input. > 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.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?003E7D36-61E0-4572-A98C-24351F6ADF5A>