From: Ronald Garcia (garcia_at_[hidden])
Date: 2002-08-14 16:23:40
David Abrahams wrote:
>----- Original Message -----
>From: "Ronald Garcia" <garcia_at_[hidden]>
>>David Abrahams wrote:
>>>I don't know what you mean; you've done the best analysis I've seen to
>>>date. Headers found through -isystem should be allowed to contain C++
>>At the time I was thinking that perhaps -isystem should not set
>>different line number flags at all, but upon checking the docs again I
>>see that it does call for special treatment of headers, at least with
>>regard to warnings.
>Really? For all platforms? Because we're not seeing any issues on other
Well, the docs say the following:
Add a directory to the beginning of the second include path,
marking it as a system directory, so that it gets the same special
treatment as is applied to the standard system directories.
My best guess is that the "special treatment" it is talking about is
whatever the compiler does when it sees the "3" flag on line numbering
directives (which are added by the preprocessor).
I have tried a few versions of gcc on linux and solaris. The difference
between linux and solaris seems to
be the addition of the "4" flag to line numbers (treat the following
text as C). Aye, there's the rub!
With that solved ( :) ), the question is what special treatment system
headers are given by gcc. The docs for the line number directives say
Source file name and line number information is conveyed by lines of
# LINENUM FILENAME FLAGS
After the file name comes zero or more flags, which are `1', `2',
`3', or `4'. If there are multiple flags, spaces separate them. Here
is what the flags mean:
This indicates that the following text comes from a system header
file, so certain warnings should be suppressed.
I presume that this is meant to allow the compiler/std-lib implementors
to get away with some warning-able constructs. My worry is that some
warnings in boost libraries might be suppressed by the use of -isystem,
but I don't know what warnings those are.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk