bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Issues with C++ overloaded math functions in math.h in the wrong sco


From: Martin Storsjö
Subject: Re: Issues with C++ overloaded math functions in math.h in the wrong scope
Date: Sun, 5 Jan 2020 00:30:18 +0200 (EET)
User-agent: Alpine 2.20 (DEB 67 2015-01-07)

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]