"Now this doesn't mean that it won't work for a platform that sets is_iec559() to false, but to me it is only guaranteed if is_iec559() is true."
Yes - I fear you are right that we are implementation-dependent.
But I can't see why a non-IEC559 platform, it is not possible for it to provide NaN support, even if it was different in detail of what was the representation of a NaN.
But to be useful would also require that isnan() knew about that platform, its peculiar implementation, and the effect of any compiler optimisations, and that the values like is_qnan etc are truthful.
(I fear that compiler providers have yet to focus on the subtle side-effects of speedups - as Thomas reports - and debugging will prove a nightmare because you find yourself in a morass of macros).
So lots more niggly work - (that I'd prefer to avoid! ;-) But the concept is NaN remains very useful to me and I use it freely, perhaps unwisely;-) It certainly beats some other arbitrary 'magic' value to represent NotANumber.
Definitely niggley - I'm currently trying to solve a bug report relating to floating point on SSE2 registers with the DAG or FTZ flags set - in these cases denorms are either not present (even though numeric_limits claims they are), or are present but get "randomly" set to zero depending upon whether we're dealing with the 32 or 64 bit architecture, and/or what instructions the compiler happens to emit where :-( Not fun! John.