This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
-isystem vs. #pragma system_header
- To: gcc at gcc dot gnu dot org
- Subject: -isystem vs. #pragma system_header
- From: Nathan Myers <ncm at cantrip dot org>
- Date: Wed, 17 May 2000 18:48:40 -0700
- Cc: libstdc++ at sourceware dot cygnus dot com
- Reply-To: gcc at gcc dot gnu dot org
(Cross-posted to libstdc++ list; please reply on the gcc list.)
In connexion with the new #pragma system_header...
When last I checked (two years back), "-isystem" in C++ was
undocumented and severely broken in C++, doing what no sane
person could conceive of wanting. If it hasn't been replaced
with something sane, maybe it would be best to get rid of it now.
Here is what I wrote then:
The current C headers use the preprocessor extension "#include_next",
which the compiler complains about when run "-pedantic".
(Incidentally, it appears that "-fpedantic" is currently ignored,
probably a bug.) The solution in the C compiler is to use
"-isystem" rather than "-I", but unfortunately in g++ this seems
also to wrap the whole header in an 'extern "C"' block, so it's
unusable for C++ headers. The correct solution appears to be to
allow the various special include-directory options, if not given
an argument, to affect subsequent include-directory options additively,
so that if one said
-pedantic -iprefix $(prefix) \
-idirafter -ino-pedantic -ino-extern-c -iwithprefix -I g++-v3 \
-iwithprefix -I g++-v3/ext
the compiler would search $(prefix)/g++-v3 and not report
pedantic warnings for files found there, but treat files in
$(prefix)/g++-v3/ext pedantically. (The undocumented semantics
of "-isystem" in g++ stink. Can they be rescinded? If not it
must be replaced with something more rationally behaved.)
I am concerned that with the new pragma it may become harder to control
warning behavior on header files. E.g., users don't ever want warnings
about system headers, but when we are developing we do want warnings.
Ideally, the headers would not have anything in them to warn about,
but we have to sub-include vendor headers we have no control over.
This can be solved using something like the above suggested feature, or
by adding (yet) another "-W" option to control how the compiler emits
warnings for system headers.
Nathan Myers
ncm at cantrip dot org