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

[Robert Lipe <robertlipe at usa dot net>]

> 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 (double)'
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. :-)

RJL