Re: How does one identify HP-UX with broken inline math funs?

[Jeffrey A Law <law at cygnus dot com>]

  In message <20000510213219.H1374@rjlhome.sco.com>you write:
  > > You missed my point that a system which depends on those inlines _not_
  > > being deleted is broken in some other way.  Rather than disable a fix
  > > which removes bogus inlines, why don't we investigate why Robert's
  > > system needs those broken inline functions.
  > 
  > (It's Bruce's system, too.   He just didn't test as thoroughly. :-)
  > 
  > OpenServer's math.h contains something like this:
  > 
  > #ifdef __cplusplus
  > inline int sqr(int i) {return(i*i);}
  > inline double sqr(double i) {return(i*i);}
  > 
  > inline int abs(int i) {return (i > 0) ? i : -i;}
  > inline double abs(double d) {return fabs(d); }
  > ...
  > 
  > 
  > If you whack these bogus inlines, then the only decl for abs you get
  > is in stdlib.h. If it's C++, the only decl it sees is for int and not
  > for double.  It isn't extern "C" and then there is no signature that
  > matches 'abs(double)'.  Thefore, libstdc++/cmath goes down in flames
  > when building C++ that passes the double to abs().
  > 
  > Yes, it's lame that stdlib.h and math.h have different rules.  Yes, it's
  > easy to argue that the system headers suck in this regard.   But if we
  > delete the system definition of abs(double) above, we get lots of failures
  > of the form:
  > 
  > ../../../egcs/libstdc++/std/complext.cc: const complex<_FLT> &) [with _FLT 
  > =
  > double]':
  > ../../../egcs/libstdc++/cinst.cc:69:   instantiated from here
  > ../../../egcs/libstdc++/std/complext.cc:184: call of overloaded `abs (doubl
  > e)'
  > is ambiguous
  > /play/negcs/gcc/include/math.h:236: candidates are: int abs (int)
  > ../../../egcs/libstdc++/cmath:40:                 float abs (float)
  > ../../../egcs/libstdc++/cmath:72:                 long double abs (long
  > ../../../egcs/libstdc++/cmath:72: double)
  > 
  > 
  > As always, I'm happy to do the right thing, I just need help figuring
  > out what it is. :-)
I have vague memories of bits you can twiddle in libstdc++ that deal
with inlined math stuff from system header files.  In fact, I thought
older stuff from SCO and hpux behaved the same when it came to the
inlined math crud in system header files.

jeff