[forwarded from http://bugs.debian.org/211586] $ cat bug-211586.cc extern "C" { #include <complex.h> } on a Linux system this is supposed to include /usr/include/complex.h, but /usr/include/c++/3.3/backward/complex.h is found. There is currently no way to exclude the deprecated or antiquated header files from the include path.
"There is currently no way" seems to me way (punt intended :) too strong! What about: -nostdinc++ -I/usr/include/c++/3.3.2 -I/usr/include/c++/3.3.2/i686-pc-linux-gnu ??
Subject: Re: no way to exclude backward C++ headers from include path paolo at gcc dot gnu dot org writes: > > ------- Additional Comments From paolo at gcc dot gnu dot org 2003-11-16 17:29 ------- > "There is currently no way" seems to me way (punt intended :) too strong! > What about: > > -nostdinc++ -I/usr/include/c++/3.3.2 -I/usr/include/c++/3.3.2/i686-pc-linux-gnu maybe too strong, but not very portable or user friendly. the user needs at least to know the exact version of gcc he uses, if configured with --with-gxx-include-dir, the name of this directory and the system alias that gcc was configured for. something like -backwardstdcinc++ to explicitely enable the backward include dir would be useful.
confirmed, changed summary based on the fact there is a way but it is not easy.
Well it is bad practice to wrap any include with `extern "c"'.
Solving for C++0x.
This seems to be fixed in all open branches (4.3+)
Isn't doing the extern "C" around standard C++ headers declared by the C++ standard as undefined behavior?
(In reply to Andrew Pinski from comment #7) > Isn't doing the extern "C" around standard C++ headers declared by the C++ > standard as undefined behavior? It is (as is doing extern "C++" around standard C++ headers, for that matter), but <complex.h> only became a standard C++ header in C++11. This bug is from 2003 and the comment before yours was from 2009, so I think <complex.h> was not a standard C++ header yet.
(In reply to Harald van Dijk from comment #8) > (In reply to Andrew Pinski from comment #7) > > Isn't doing the extern "C" around standard C++ headers declared by the C++ > > standard as undefined behavior? > > It is (as is doing extern "C++" around standard C++ headers, for that > matter), Where does it say that? > but <complex.h> only became a standard C++ header in C++11. This > bug is from 2003 and the comment before yours was from 2009, so I think > <complex.h> was not a standard C++ header yet. Agreed. But there is no complex.h in the backward directory now. The contents of that directory are: auto_ptr.h backward_warning.h binders.h hash_fun.h hash_map hash_set hashtable.h strstream The <strstream> header is required for standard conformance, so excluding that directory would make it impossible to use that standard header. The other headers seem unlikely to conflict with any headers in /usr/include (which was the original subject of this PR). Can we close this now?
(In reply to Jonathan Wakely from comment #9) > (In reply to Harald van Dijk from comment #8) > > (In reply to Andrew Pinski from comment #7) > > > Isn't doing the extern "C" around standard C++ headers declared by the C++ > > > standard as undefined behavior? > > > > It is (as is doing extern "C++" around standard C++ headers, for that > > matter), > > Where does it say that? It's the exact same rule as for extern "C", [using.headers]p3. (And yes, it does make a difference to not having extern "C++" around it and can cause breakage, this is not purely hypothetical, but it's much less likely to cause problems than extern "C".) > > but <complex.h> only became a standard C++ header in C++11. This > > bug is from 2003 and the comment before yours was from 2009, so I think > > <complex.h> was not a standard C++ header yet. > > Agreed. But there is no complex.h in the backward directory now. >[...] > Can we close this now? Testing with GCC 11 as provided by Ubuntu, including <complex.h> will cause GCC's c++/11/complex.h to be included, both in C++03 and in C++11 modes, but in C++03 it just delegates to glibc's <complex.h>. To me, that looks like it's fixed.
[using.headers] says you can't include a header inside a declaration or definition. A linkage specification is a declaration in terms of the C++ grammar, but I'm not sure that's what [using.headers] means. It doesn't actually declare anything. I'll open an LWG issue to get clarification. Anyway, let's close this.
(In reply to Jonathan Wakely from comment #11) > I'll open an LWG issue to get clarification. LWG agrees that it's ill-formed (no diagnostic required) to include standard headers inside a linkage-specification. Libstdc++ tries to makes it work as QoI, e.g. r12-4367-gc1b6c360fcf3fc