we are currently using clang-cl (build with LLVM7) in our project, which previously used the MSVC2017 compiler. We noticed a major difference with the representation of the NAN value.
Clang generates 0x7FF8000000000000 for an NAN
MSVC generates 0xFFF8000000000000 for an NAN
This difference leads to problems with C#, because it interacts with our C++ code and ‘misses’ the NAN.
Is there a way to change the representation of the NAN via a compiler flag?
Could we also change the source code of clang to force this representation of NAL? Or is this to much effort for a workaround?
C# can handle NaN correctly. It is important NOT to do "if (foo ===
double.Nan)" but instead "if(double.IsNan(foo))". C# code that
compares with double.NaN is simply buggy.
Arithmetic should work correctly in any case.
Seems like we are not using 'double.Nan' but foo.toString and then locating there term "nan".
That's a weird way to do it But it should return
NumberFormatInfo.NanSymbol from System.Globalization, which by default
is "NaN" (though it has a setter!).
It is doesn't, then that's a bug in double.toString() and you should
take that up with Microsoft.
We found a bug in our code - but I still wonder why Clang does generate two different versions of NaN.
(See my other mail for further information)
There are 2^53 - 2 different versions of NaN in IEEE double precision.
Correct software or hardware must accept any of them.
(the missing 2 are +/- infinity)
At least I understood that now better ;D