Peter Moulder wrote:

isnan unfortunately isn't part of the C++ standard.

Availability of isnan, std::isnan, _isnan and friends can vary according to whether <math.h> has been #included (perhaps indirectly such as by C-based libraries that we use) and whether <cmath> has been #included (perhaps indirectly such as by standard C++ headers that we #include).

We may need to write our own isnan.h header.

Does anyone know whether `x != x' is a portable definition of isnan?

(`(libc)FP Comparison Functions' says that `!=' doesn't raise an exception for NaN in IEEE arithmetic, btw.)

pjrm.

You might look at the macros that are in math.h or cmath or wherever they are. That might be the proper way.

But..... it is possible that this needs to be another test in configure.in.

Or... if this is a switch in config.h.in, then we can have Unices do it via ./configure, and have it hardcoded for Win32.

There seem to be three ways that work on various versions of gcc:

1: Use math.h and call isnan(). 2: Use math.h and call std::isnan() 3: Use <cmath> and call std::isnan()

Bob

Peter Moulder wrote:

We may need to write our own isnan.h header.

I think you are right. In the mingw implementation, <math.h> is actually #undef-ing isnan() when the "c++ bits" are included for __GLIBCPP__.

Defines in config.h are thus ignored. So much for that idea. I think the reason is that Mingw's #include files are broken, as far as isnan() is concerned. Google had some other people's problems with this.

So, as a temporary fix, 1. I added a trivial isnan.h to /src 2. On files that need isnan(), made that the last #include 3. Named the new definition isNaN() in order to avoid name conflicts.

Seems to compile/link on Linux and Mingw nicely now. Someone might try OSX. I would not be surprised if the latest MinGW has the definitions fixed.

Bob