Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: Use of SNaN



On Jan 9 2012, Michel Hack wrote:
Vincent Lef�vre wrote:

Sorry, I should have been more accurate.  I meant that it can be
possible in languages (at least in C), partly based on the fact
that IEEE 754 specifies the sNaN encoding.  In C, this can be
done by storing a sequence of bytes using a union.  Of course,
this can only be implementation-defined because IEEE 754 specifies
the encoding only as a bit-string (not as a sequence of bytes).

Not even that.  That trick is undefined behaviour, and won't always
work.  In C90, you could have used a cast to 'unsigned char *' to do
it without explicitly undefined behaviour, but C99's introduction of
'effective type' probably breaks even that.  That was supposedly to
assist compilers that use assumptions about type implying aliasing
for extra optimisation - i.e. explicitly excluding your technique.

Unfortunately sNaN encoding is specified only for DFP by 754-2008.
For BFP the encoding is only suggested:  the 1st bit of the trailing
significand SHOULD be 1 for qNaN and 0 for sNaN.  That's because
there is existing hardware (HP's PA-RISC, I believe) that uses the
opposite polarity.

I just re-read 6.2.1 and noticed that even the position of the bit
is only a SHOULD, never mind the polarity.  But I think everybody
does use the same bit.  (This is why stds-754 is CCed.)

They certainly used not to - if I recall, it wasn't even a bit on
some systems, but I may be misremembering there.


Regards,
Nick Maclaren.