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.