On Sat, 4 Jan 2020, Bruno Haible wrote:
Hi Martin,
In this particular case, this math.h header ends up included in a context
wrapped in 'extern "C" {}' surrounding it, which breaks the C++ function
overloading.
The general convention is that header files must be included outside of
any 'extern "C" {}' or 'extern "C++" {}' context. See [1][2].
The series of headers leading up to this is a bit long...
- The source file includes some windows header
- windef.h includes winnt.h within an extern "C" block. windef.h also
includes minwindef.h, which also includes winnt.h within an extern "C"
block. Not sure if this really is the right thing to do or not.
- The mingw-w64 winnt.h has one extern "C" block covering the whole file,
one over a section of the file, and one block specifically around an
include of x86intrin.h. Not sure if the former two are right, but
x86intrin.h and the files that it includes at least seem like they
really need extern "C" around them.
- *intrinh end up including mm_malloc.h (this also goes for gcc), and
mm_malloc.h includes stdlib.h (also goes for gcc)
- libc++'s stdlib.h (which is included before the normal stdlib.h)
includes math.h since https://reviews.llvm.org/D60097 (this was also the
root cause for an issue discussed earlier), and math.h (which first hits
gnulib's math.h) now tries to declare the overloaded set of
float/double/long double rpl_isfinite functions, which fails since
we're in an extern "C" scope.
I'm not really sure which bit in this chain that actually can be
considered wrong, but I wanted to post the issue I'm seeing at least...
windef.h and winnt.h are wrong.
Fair enough - I'll try to see if I can fix that. Apparently it's in common
use around large portions of the headers there, but I can at least fix the
paths that lead up to this case.
Thanks!
// Martin