[R] ISNAN() broken? in ver 2.x on MacOS X

[Bill Northcott]

I see you are quite correct that IEEE_754 is defined in Rconfig.h on 
MacOS X.  However, I was building against a standalone libRmath v1.9.1. 
  So I was including Rmath.h only and IEEE_754 was not defined.  The 
result was that I got R_IsNaNorNA in the preprocessed source.

I finally found it.  The culprit is
#include <iostream>
which is used in our real code

If I preprocess the following code then the substitution is ISNAN() --> 
(isnan(x)!=0)
#include <iostream>
#include <R.h>
#include <Rmath.h>
ISNAN(x);

Removing the #include <iostream> the substitution becomes
ISNAN(x)   --> (( ( sizeof ( x ) == sizeof(double) ) ? __isnand ( x ) : 
( sizeof ( x ) == sizeof( float) ) ? __isnanf ( x ) : __isnan ( x ) 
)!=0)
which is correct.

This behaviour is the same with both gcc 3.3 and pre-release gcc 4.0 on 
MacOS X 10.3.7.

Is this a bug we should report to someone such the gcc maintainers?

Bill Northcott
On 04/01/2005, at 1:48 PM, Thomas Lumley wrote:
>> In R 1.9.1 Arith.h and Rmath.h contained code like
>>
>> #ifdef IEEE_754
>> # define ISNAN(x) (isnan(x)!=0)
>> #else
>> # define ISNAN(x)      R_IsNaNorNA(x)
>> #endif
>> #define R_FINITE(x)    R_finite(x)
>> int R_IsNaNorNA(double);
> Although you have clearly gone to some effort to diagnose this, I 
> think your diagnosis is incorrect.
>
> 1) In R 1.9.1 IEEE_754 was #defined on OS X, so we would already have 
> had
>   #define ISNAN(x) (isnan(x)!=0)
>
> 2) The gcc C preprocessor documentation says
>   "When the preprocessor expands a macro name, the macro's expansion
>   replaces the macro invocation, then the expansion is examined for 
> more
>   macros to expand. For example,
>
>      #define TABLESIZE BUFSIZE
>      #define BUFSIZE 1024
>      TABLESIZE
>           ==> BUFSIZE
>           ==> 1024
>
>   TABLESIZE is expanded first to produce BUFSIZE, then that macro is
>   expanded to produce the final result, 1024."
>
> and while I haven't been able to find anything definitive about the 
> ANSI standard, the gcc documentation usually flags extensions fairly 
> well and in any case you are presumably using gcc (though you don't 
> say explicitly).
>
>
> A work-around would be to use isnan() rather than ISNAN().
>
>
> 	-thomas
>