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: Bruno Haible
Subject: Re: Issues with C++ overloaded math functions in math.h in the wrong scope
Date: Sat, 04 Jan 2020 13:32:21 +0100
User-agent: KMail/5.1.3 (Linux/4.4.0-170-generic; KDE/5.18.0; x86_64; ; )

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




reply via email to

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