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
_______________________________________________ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel