On 7 January 2016 at 13:36, Jonathan Wakely wrote: > On 7 January 2016 at 13:14, Jonathan Wakely wrote: >> On 6 January 2016 at 21:05, Jonathan Wakely wrote: >>> 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. >> >> I have a working patch (to be posted later today) which fixes this >> issue, and LWG 2294. >> >> However, because my patch means that <math.h> always includes <cmath> >> it makes it much easier to hit PR48892 (aka PR60407 aka PR68984). I > > Oops, typo, I meant PR48891. > >> have a workaround for that, which is fragile and ugly. A better >> solution would be for glibc's mathcalls.h to suppress the non-generic >> Unix98 isnan and isinf functions when included from C++, as Joseph >> suggested at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54130#c14 >> >> Libstdc++ can #undef isinf and #undef isnan to remove the C99 macros, >> but it can't undefine functions, we'd need to use fixincludes for >> that. Maybe it's time to address the isinf/isnan issue properly.
It took a bit longer than I expected, but there's a patch for C++-conforming <math.h> and <stdlib.h> wrappers at https://gcc.gnu.org/ml/gcc-patches/2016-01/msg00448.html which relies on the fix for the std::isinf and std::isnan bug at https://gcc.gnu.org/ml/gcc-patches/2016-01/msg00416.html with an accompanying glibc bug report at https://sourceware.org/bugzilla/show_bug.cgi?id=19439 Phew, time for the weekend.
