R help - Jan 2005 - ISNAN() broken? in ver 2.x on MacOS X

I have a problem building an extension using ISNAN() on R version 2.0.x.

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);
int R_finite(double);

which works.

R 2.0.x has
# define ISNAN(x) (isnan(x)!=0)
unconditionally.

This breaks because on MacOS X in /usr/include/architecture/ppc/math.h 
isnan() is itself a macro thus:
#define      isnan( x )         ( ( sizeof ( x ) == sizeof(double) ) ?  
          \
                               __isnand ( x ) :                          
        \
                                 ( sizeof ( x ) == sizeof( float) ) ?    
         \
                               __isnanf ( x ) :                          
        \
                               __isnan  ( x ) )

This macro is not substituted because substitution is not recursive. So 
the build breaks with 'error: `isnan' undeclared'.

How can I fix this?

Bill Northcott

On Tue, 4 Jan 2005, Bill Northcott wrote:
> I have a problem building an extension using ISNAN() on R version 2.0.x.
>
> 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);
> int R_finite(double);
>
> which works.
>
> R 2.0.x has
> # define ISNAN(x) (isnan(x)!=0)
> unconditionally.
>
> This breaks because on MacOS X in /usr/include/architecture/ppc/math.h 
> isnan() is itself a macro thus:
<snip>
> This macro is not substituted because substitution is not recursive. So the
> build breaks with 'error: `isnan' undeclared'.
>
> How can I fix this?

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

R has no such bug number, nor does any search I do come up with anything 
similar.

In any case, please do read the R posting guide, as this is not a suitable 
topic for R-help and I have diverted it to R-devel where it belongs.

On Tue, 4 Jan 2005, Bill Northcott wrote:
> This sort of confirms that it is a bug.
>
>> From: Andrew Pinski <pinskia@physics.uc.edu>
>> Date: 4 January 2005 7:39:38 PM
>> To: Bill Northcott <w.northcott@unsw.edu.au>
>> Cc: gcc@gcc.gnu.org
>> Subject: Re: C++ header file problem - is this a bug?
>> 
>> 
>> On Jan 4, 2005, at 2:13 AM, Bill Northcott wrote:
>> 
>>> Is this a bug or is it expected behaviour and if so why?
>> 
>> Yes this is a bug but it is already filed see PR 14608.
>> 
>> Thanks,
>> Andrew Pinski
>
>
-- 
Brian D. Ripley,                  ripley@stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595