On 18 Sep 2015, at 08:27, Roland Haas rhaas@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.