On 04/01/2005, at 11:52 PM, Peter Dalgaard wrote:
Prof Brian Ripley <[EMAIL PROTECTED]> writes:

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

The Cc: line suggests that it is a gcc PR#. Guess who fell into the same trap...

That is indeed a gcc bugzilla problem report number. It seems the gcc maintainers are agreed that it is too hard to fix at this time. The workarounds suggested in the PR 14608 don't work on MacOS X, and probably don't work on other platforms because the undefs of the math.h macros in cmath are not conditional.

So what might be the 'take away' for R?  Possibilities:

1. Amend the documentation: add a note to 'Missing and IEEE special values' in 'Writing R extensions' to the effect that the macros should not be used with C++. Currently they will break on several platforms.

2. The work-around that strikes me is to use R_IsNaN instead, which was the approach used in R v1.9 for non-IEEE platforms and when used standalone. Unfortunately this API was changed between v1.9 and v2.0. That is no problem when building against an installed R as there is a macro for the Version. However, if building standalone, I can see no way to get the version short of an autoconf macro to test for the symbols in the library.

3. Perhaps the macro substitution of R_IsNaN for ISNAN etc. could be reintroduced into v2.0.x conditional on C++. That might need a new ISNA() macro.

Bill Northcott

______________________________________________
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Reply via email to