LilyPond 2.5: isinf macro/function/template

[Andreas Scherer]

Hello list,

I have tried to analyze the "isinf issue", resulting from my "#include 
cleanup" patch for LilyPond 2.5, and want to submit the following results, 
created with gcc/g++/libc/libstdc++ 3.3.4 on SuSE Linux 9.2.

If you look at the LilyPond C++ sources you find that the issue with "isinf" 
seems to have been addressed before.  Module <flower/libc-extension> looks 
for a /macro/ "isinf" and if such a thing does not exist /and/ if the initial 
configuration finds no "isinf" function in the system libraries 
(!HAVE_ISINF), a local version of "int isinf(double)" is defined.  (I have no 
idea whether this situation ever arises.)  Module <lily/liy-guile> explicitly 
has a "MacOS fix" (with an additional "FIXME"), because "source-file.hh" 
somehow pulls in <cmath>, thus overriding any "isinf" macro definition.  Of 
course, after my change in <lily/lily-guile.cc> (s/<math.h>/<cmath>/ et al.), 
this "fix" does no longer work.

The attached archive contains two source files in C and C++ calling "isinf" in 
various incantations.  The C version uses <math.h> as the interface and in 
one situation I can bring gcc to at least issue a warning regarding an 
"implicit declaration of function isinf" after the line "#undef isinf".  The 
C++ version uses <cmath> as the interface and calls "isinf" (before and after 
"#undef isinf"), "::isinf", and "std::isinf" without complaint.  So, on this 
GNU/Linux system, there is no real problem with "isinf", either as a macro, a 
function, or a template.

According to "man isinf" on my configuration, "isinf/isnan/finite" are 
functions (sic!) "conforming to BSD 4.3".  It further states that "C99 
provides additional macros (!), such as the type-independent fpclassify(), 
isinf(), and isnan()" (and with option "--std=c99" plus "#undef isinf" in the 
code, gcc 3.3.4 issues the above-mentioned warning).

IIRC, MacOS X is based upon "BSD", so it is unclear to me, how this 
"BSD-conforming" function/macro should be unavailable for use in C++ 
programs.  My best guess is that BSD /only/ has the "isinf" /macro/ in 
<math.h> and no underlying "isinf" system /function/ reachable through a 
different interface (like said /template function/ in <cmath> on Linux) /and/ 
<cmath> "#undef"ines exactly this macro.

Hopefully, some member with MacOS eXperience can find a compliant solution to 
the problem.

Take care
-- 
Andreas Scherer
Saarstraße 76, 52062 Aachen, Germany
http://people.freenet.net/andreas.scherer

isinf.tar.gz
Description: application/tgz