Does posix say anything about the sign in NaNs ?

[Bruce Evans]

On Sat, 27 Dec 2014, Garrett Wollman wrote:

> <<On Fri, 26 Dec 2014 01:00:48 +1100 (EST), Bruce Evans <brde at 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.

Bruce