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

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

The following reply was made to PR c/2677; it has been noted by GNATS.

From: "Ronald F. Guilmette" <rfg@monkeys.com>
To: "Joseph S. Myers" <jsm28@cam.ac.uk>
Cc: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org
Subject: Re: c/2677: Need something to #ifdef on when -pedantic/-pedantic-errors 
Date: Sat, 28 Apr 2001 13:27:03 -0700

 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.