[ODE] 0.6-RC1 is Released

[Bram Stolk]

Rodrigo Hernandez wrote:

> There are 3 Versions:
> 
> HAS___ISNANF means use __isnanf
> HAS__ISNANF means use _isnanf
> HAS_ISNANF means use isnanf
> 
> I am not sure which one VC++ uses, probably one of the later 2, you may 
> replace the default one in common.h to use whichever VC++ uses too.

I thought that the default VC was the _isnanf variant?
If that is so, the common.h looks good to me:

#ifdef HAVE___ISNANF
#define dIsNan(x) (__isnanf(x))
#elif defined(HAVE__ISNANF)
#define dIsNan(x) (_isnanf(x))
#elif defined(HAVE_ISNANF)
#define dIsNan(x) (isnanf(x))
#else
   /*
      fall back to _isnanf which is the VC way,
      this may seem redundant since we already checked
      for _isnan before, but if isnan is detected by
      configure but is not found during compilation
      we should always make sure we check for __isnanf,
      _isnan and isnan in that order before falling
      back to a default
   */
#define dIsNan(x) (_isnanf(x))
#endif

Because:
If I grep on NAN in build/config-default.h I get no matches,
so it should be using _isnanf()

This is weird...
If we can't solve this, I'll yank the asserts from
test_basket.
The isnan was only used as paranoia asserting there.
(Which normally is a good thing, but not if isnan is
  unreliable)

   Bram



> Cheers.
> _______________________________________________
> ODE mailing list
> ODE at q12.org
> http://q12.org/mailman/listinfo/ode