On 11/04/2016 04:10, Bjorn Reese wrote:
Another problem related to the above is that the NaN payload is implementation-defined, so even if the exact bit-pattern is preserved, programs compiled with different compilers may interpret the payload differently.
While that's true, surely any compiler/library should treat any NaN bit pattern as returning true from isnan() and friends, even if it is not bit-identical to the NaN that the compiler/library would generate itself. Using it in a further calculation might result in a different NaN bit pattern, but that's expected behaviour anyway. So at least in theory it should work unless there are bugs in the compiler/library or in the application (eg. it is not an error if <external NaN> != <internal NaN>; it's an app bug if it makes an equality assumption -- for that matter equality can't even be assumed between internal NaNs).