Re: Use of SNaN
On Jan 10 2012, Vincent Lefevre 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.
This trick has a well-defined behavior as long as the object is
supported by the implementation. Now, an implementation is free
to regard sNaN objects as undefined behaviour. But in such a case,
I'm not sure that it could claim conformance to IEEE 754 (while
we are in the context of IEEE 754). With GCC, you can use the
-fsignaling-nans (experimental) option to support signaling NaNs.
I am sorry, but that is wrong, according to several vendor
statements made to WG14, the majority view on the WG14 reflector,
and my experience. I was involved with WG14 at the time, with a
particular interest in this aspect, and was supporting a wide range
of compilers for HPC systems. See below :-(
The undefined behaviour has nothing to do with the representation,
but is whether the compiler is allowed to use its knowledge of
what was last stored in a union to produce code that will break
that trick. That was implementation-defined (which can include
undefined!) in C90, I agree, but is undefined in C99 by 6.5
paragraph 7. The point is that storing the value is still
implementation-defined, but using it as a floating-point value
is not.
I accept your point that the wording in the standard is compatible
with your position, but it is ALSO compatible with the one I have
just described. I raised closely related points more than once,
when the I (as part of the BSI) was objecting to the ambiguities
in the specification of effective type, and got the majority
response I described above.
Don't blame me - I and the BSI voted "no" on that horror!
Regards,
Nick Maclaren.