Date: Sun, 28 Dec 2014 21:38:06 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Garrett Wollman <wollman@csail.mit.edu> Cc: Pedro Giffuni <pfg@freebsd.org>, freebsd-standards@freebsd.org Subject: Re: Does posix say anything about the sign in NaNs ? Message-ID: <20141228201637.F1073@besplex.bde.org> In-Reply-To: <21663.14861.388944.805245@khavrinen.csail.mit.edu> References: <549B1115.8000909@FreeBSD.org> <20141225235228.H927@besplex.bde.org> <21663.14861.388944.805245@khavrinen.csail.mit.edu>
index | next in thread | previous in thread | raw e-mail
On Sat, 27 Dec 2014, Garrett Wollman wrote: > <<On Fri, 26 Dec 2014 01:00:48 +1100 (EST), Bruce Evans <brde@optusnet.com.au> said: > >> 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: > > An old draft of the C standard is not necessarily relevant here, since > POSIX may place requirements on implementations beyond those of C. I usually quote the old draft since C and POSIX have no newer text versions. C11 (n1570.pdf) hasn't changed anything relevant. POSIX wouldn't say anything different about this (except possibly to add bugs) since specification of floating point belongs in lower level standards. > The 2008 POSIX standard (aka SUSv7) had this to say (XBD7 p. 247, > <float.h>): > > An implementation may give zero and non-numeric values, such > as infinities and NaNs, a sign, or may leave them > unsigned. Wherever such values are unsigned, any requirement > in POSIX.1-2008 to retrieve the sign shall produce an > unspecified sign and any requirement to set the sign shall be > ignored. > > I haven't checked the current edition to see whether it differs in > this regard, but I doubt it. Not very relevant. This just doesn't require or disallow any particular hardware support for signed NaNs (or even signed zero or signed infinities). Any such requirement would be a large bug, since it would force loss of features or slow virtualization to modify the features. All (?) hardware supported by FreeBSD supports signed NaNs, zeros and infinities, and so does FreeBSD (tested on amd64, ia64, i386 and sparc64). FreeBSD is supposed to support everything in Annex F if the hardware supports it, and libm would break if signed infinities were not supported by the hardware. It might also break if signed zeros are not supported by the hardware. Signed NaNs are unumportant. > XSH7 page 932 (fscanf()) additionally requires: > > If the fprintf ( ) family of functions generates character > string representations for infinity and NaN (a symbolic entity > encoded in floating-point format) to support IEEE Std > 754-1985, the fscanf ( ) family of functions shall recognize > them as input. I see this section in the 2007 draft version, marked as added. This is badly written, so that it adds nothing. C99 already requires nan() and strtod() to "recognize" (i.e., just parse) character string representations in specific formats. It is a fuzzy for fscanf() and fprintf(), but clearly allows the specific formats (and no others) to be written by fscanf() and read by fprintf(). But it doesn't require that the (non-)values written written can be read back, except it specifies breakage for signaling NaNs (that they cannot be read back). Neither does the above. Invalid formats are specified to be silently converted to "NAN". The meaning of the formats (and the precise set of valid ones) is implementation-defined. > My view would be that FreeBSD is free to determine that NaN is an > unsigned value, and no conforming application can distinguish signed > NaNs (either positive or negative) from unsigned NaNs. Ineed, no (strictly) conforming application can do anything with NaNs (they might not even exist). Even with Annex F, everything about their bits is implementation-defined or unspecified. Brucehome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141228201637.F1073>