Does posix say anything about the sign in NaNs ?
Pedro Giffuni
pfg at freebsd.org
Thu Dec 25 14:54:44 UTC 2014
Hello;
> Il giorno 25/dic/2014, alle ore 09:00, Bruce Evans <brde at 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.
More information about the freebsd-standards
mailing list