From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Ronald F. Guilmette" To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org Subject: Re: c/2677: Need something to #ifdef on when -pedantic/-pedantic-errors Date: Sat, 28 Apr 2001 13:36:00 -0000 Message-id: <20010428203601.1826.qmail@sourceware.cygnus.com> X-SW-Source: 2001-04/msg00689.html List-Id: The following reply was made to PR c/2677; it has been noted by GNATS. From: "Ronald F. Guilmette" To: "Joseph S. Myers" 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 , 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.