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.
Bruno
[1] https://lists.gnu.org/archive/html/bug-gnulib/2019-03/msg00060.html
[2] https://lists.gnu.org/archive/html/bug-gnulib/2019-03/msg00064.html
