[libcxx] [test] Initialize local doubles to NaN.
Fixes MSVC "warning C4701: potentially uninitialized local variable 'meow' used".
STL_MSFT on Apr 27 2016, 2:31 PM.Authored by
I don't know how the libc++ folks feel about this, but our usual policy in Clang and LLVM is that we don't add bogus initializers to shut up incorrect "maybe used uninitialized" compiler warnings, because these initializers prevent tools like MSan and valgrind from catching the bug if the variable ever is actually used uninitialized. For this reason, we turn off the portion of GCC's -Wuninitialized warning that has false positives too.
I'd be happy to deal with this in another way. Would you accept _MSC_VER-guarded pragmas to silence such warnings? I didn't see an easy way to rework the logic here so that the variables are obviously initialized on every codepath, which would be the ideal pragma-less solution.
According to my equally vague understanding, a quiet NaN (if used in operations, instead of being overwritten with something valid) will silently propagate down to the assert, which will complain that it's not equal to whatever you were expecting. That would detect any unintentional use of the NaN-initialized value.
A signaling NaN will (I think) raise an FP exception when you try to do anything with it, which may not be treated similarly by your test harness. (I'm not a good person to answer this question, as C1XX has bug/limitations with returning signaling NaNs, to the point where this function in numeric_limits is essentially useless.)
A quiet nan is the right tool. A signaling nan is nothing more than a 40-year-old design flaw. A quiet nan is "sticky" in that if you try to compute with it, the result is quiet nan. But you can assign a valid number to something containing a quiet nan. So if your answer has nans in it, you know you didn't initialize something properly somewhere.