Re: c/2677: Need something to #ifdef on when -pedantic/-pedantic-errors

["Ronald F. Guilmette" <rfg at monkeys dot com>]

In message <Pine.LNX.4.32.0104282050500.6083-100000@kern.srcf.societies.cam.ac.
uk>, you wrote:

>On 28 Apr 2001 rfg@monkeys.com wrote:
>
>> Build and install the glib library (version 1.2 or 1.3.4)
>> and associated include files.  Then compile something that
>> includes "glib.h" and do so while using the -pedantic or
>> -pedantic-errors option.  You'll get warnings or errors,
>> respectively, because glib.h uses the non-standard GNU
>> notation for macros accepting variable numbers of arguments.
>
>3.0 does not give these warnings for system headers, or macros defined in
>system headers.

I think that you are confused.

I never said anything in my bug report about ``system headers''.

I'm talking about headers in general.

Do you (incorrectly) assume that each and every set of headers that gets
installed each time I build and install any pre-canned third-party package
on my system is somehow going to magically qualify as a ``system header''?

>(You'll need to ensure that the glib headers do count as system headers,

No, I won't, because they aren't.

Besides which, that's not my job.  I didn't write the package, and I don't
maintain it.

I'm just trying to use the bloody thing without gcc giving me a lot of
spurious grief.

>e.g. by adding
>
>#if defined(__GNUC__) && (__GNUC__ > 2 || __GNUC_MINOR >= 97)
>#pragma GCC system_header
>#endif

This doesn't solve the problem at all.

I'm afraid that you have not understood the problem.

The notion of ``system headers'' comes from the C standard itself and it
refers to header files that are part and parcel of the LANGUAGE IMPLEMENTA-
TION.  The ANSI C standard allows such files to contain any arbitrary
gibberish whatsoever (and in fact, they may not exist at all) as long as 
they APPEAR to exist and as long as they APPEAR to export the required
macros and functions and as long as whatever they do contain (if they
do in fact exist as separately identifiable text files at all) does not
cause the compiler to choke.

Header files which are parts of third-party packages clearly do not qualify
as being a part of the LANGUAGE IMPLEMENTATION, and they SHOULD NOT be
confused with such.

My bug report still stands.  Just as use of the -ansi option causes the
__STRICT_ANSI__ preprocessor symbol to become predefined (so that BOTH
``system'' and ``application'' headers files can conditionalize on that)
the -pedantic and -pedantic-errors options should cause the automatic
pre-definition of a similar (but different) special preprocessor symbol
so that both ``system'' and ``application'' code (and not just header
files... we could be talking about .c and/or .C files here too) can
conditionalize on that, and can be made to Do The Right Thing in either
case.

In fact, in an ideal world, virtually EVERY gcc/g++ compilation option
(with the possible exception of the -W options) would be represented by
a corresponding preprocessor symbol (which would be predefined, auto-
magically, if the corresponding compilation option were used).  Right
now, gcc/g++ only allows you to conditionalize on a couple of the possible
compilation options (-ansi/__STRICT_ANSI__ and -O/__OPTIMIZE__) and in
my opinion, that's not nearly enough.