ian.hinder at aei.mpg.de
Fri Sep 18 02:57:36 CDT 2015
On 18 Sep 2015, at 08:27, Roland Haas <rhaas at aei.mpg.de> wrote:
> Hello all,
>> Don't use NaN for poison! If you do, then you cannot tell the
>> difference between NaNs generated because of numerical problems, and
>> poison generated due to programming bugs.
> Not true really. There are multiple "nan" values. See eg
> http://en.cppreference.com/w/c/numeric/math/nan and if you use nan("17")
> for poison you will be able to tell it apart from the nan that you get
> out of 1./0 and sqrt(-1.) type errors.
> Attached it is a simple C99 program to demonstrate this. Basically it
> means that to detect poison you need to use memcmp (which we already do)
> and that in floating point arithmetic a nan("17") propagates as a
> nan("17") when combined with other non-NaN numbers but may be wiped when
> combined with a NaN (which would also wipe a non-NaN poison value though).
Fascinating. I had no idea that there was more than one NaN value. The wikipedia page <https://en.wikipedia.org/wiki/NaN> explains it is more detail than the cppreference page.
The conversion from the character representation to the binary representation appears to not be defined by the C/C++ standard, so presumably is left up to the compiler / libc / platform. Also, I suspect that this usage of NaN payloads is not well supported by most analysis software.
Apart from those concerns, yes, it would be very good to use a specific type of NaN to represent poison.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Users