lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Missing isnan, isinf?


From: Don Blaheta
Subject: Re: Missing isnan, isinf?
Date: Sat, 4 Feb 2006 16:09:56 -0600
User-agent: Mutt/1.2.5.1i

Primarily to the Mac OS X crowd: Ok, so I sat down and did some
sleuthing work today.  The reason the compiler thought isinf and isnan
were never defined has to do with the layout of header <cmath>.  A
trivial file that triggers the problem is

  #include <cmath>
  using namespace std;
  
  int main () {
    if (isinf (5) )
      return 0;
    else
      return 1;
  }

If I replace <cmath> with <math.h> or "math.h", it works.
Unfortunately, many other standard headers (e.g. <iostream>) do include
<cmath>, so even changing our includes to <math.h> wouldn't help.

Here's the problem.  Omitting irrelevant lines, <cmath> is laid out as
follows:

  #include <math.h>

  #if _GLIBCPP_USE_C99
  namespace __gnu_cxx
  {
    template<typename _Tp>
      int     
      __capture_isinf(_Tp __f) { return isinf(__f); }
  }
  #endif

  #undef isinf

  #if _GLIBCPP_USE_C99
  namespace __gnu_cxx
  {
    template<typename _Tp>
      int
      isinf(_Tp __f) { return __capture_isinf(__f); }
  }
  namespace std
  {
    using __gnu_cxx::isinf;
  }
  #endif

So: under some circumstances (when _GLIBCPP_USE_C99 is true), we want
to shift isinf et al into namespaces.  We capture the existing (macro)
definition into a function, then undefine the macro, then define a
function under the original name inside the namespace.  Clever!  And
then we import the definition into the std namespace.

The PROBLEM is, that even when we're not interested in performing all
these shenanigans, it STILL UNDEFINES THE GODDAMN MACRO.  This has
apparently been a known bug for many years now, dating back to Apple's
gcc-3.1 release, but although I find a lot of people noting the error
and acknowledging the error, Google is not turning up any standard
fixes.  It seems like absorbing the undefs into the _GLIBCPP_USE_C99
section would be easiest, but I don't know if it'd be correct.  Any
ideas?  And presumably you need a workaround for people who aren't
willing to go in and patch /usr/include/gcc/darwin/3.3/cmath by hand....

-- 
-=-Don address@hidden<http://www.blahedo.org/>-=-
"When I was an altar boy, the most coveted job was to be "thurifer," or
incense hassler. This job was great because you got to light the
charcoal in the thurible (incense burner) before the service, which gave
my natural desire to play with matches a religious significance that I
still feel when lighting coals in the Weber."           --Cecil Adams




reply via email to

[Prev in Thread] Current Thread [Next in Thread]