On 4 January 2016 at 09:32, Florian Weimer wrote:
> On 12/31/2015 01:31 PM, Jonathan Wakely wrote:
>> On 31 December 2015 at 11:37, Marc Glisse wrote:
>>> That's what I called "bug" in my message (there are a few bugzilla PRs for
>>> this). It would probably work on Solaris.
>>
>> Yes, the <math.h> case is still a mess in the standard and in glibc.
>> The "only in namespace std in the second case" part is what I meant
>> was not accurate. C++11 changed to allow <cmath> to declare it in the
>> global namespace, but as you say didn't go far enough.
>
> What changes are needed in glibc?
(Should we move this to the libstdc++ list?)
The problem can either be solved purely in libstdc++, by providing our
own <math.h> that does #include_next <math.h> to get the libc header
and then adds the overloads required by C++, or it can be solved by
adding those overloads to the libc header directly.
The latter is what Solaris does, and is similar to what glibc already
does for strchr etc. in <string.h>. It would mean something like:
#if __cplusplus
namespace std {
inline float abs(float __x) { return ::fabsf(__x); }
inline double abs(double __x) { return ::fabs(__x); }
inline double abs(long double __x) { return ::fabsl(__x); }
inline float fabs(float __x) { return ::fabsf(__x); }
inline double fabs(double __x) { return ::fabs(__x); }
inline double fabs(long double __x) { return ::fabsl(__x); }
// Similar overloads for other math functions
}
using std::abs;
// ...
#if __cplusplus > 201103L
namespace std {
// similar overloads for C99 isfinite etc.
}
using std::isfinite;
// ...
#endif
#endif
However, this is a lot more work for glibc than the relatively simple
strchr/memchr case.
I have been meaning to try solving it in libstdc++ with a new <math.h>
that includes the libc one and extends it, to see how well that works.
I haven't had time to try that, so it would be premature to ask for
changes to be made to glibc when I don't know if they are necessary or
would even be the best solution.
