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

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

[Joseph S. Myers]

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

From: "Joseph S. Myers" <jsm28@cam.ac.uk>
To: "Ronald F. Guilmette" <rfg@monkeys.com>
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 21:51:39 +0100 (BST)

 On Sat, 28 Apr 2001, Ronald F. Guilmette wrote:
 
 > 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-
 
 ISO 9899 does not contain the term.  The GNU CPP manual defines how it is
 used in a GCC context: to mean headers found in specific directories, and
 those otherwise marked as system headers.  The exclusion of warnings from
 system headers is a pragmatic matter, since they aren't under the control
 of the user and it reduces (in some cases) the amount of work fixincludes
 needs to do.
 
 > In fact, in an ideal world, virtually EVERY gcc/g++ compilation option
 > (with the possible exception of the -W options) would be represented by
 
 But -pedantic and -pedantic-errors are essentially -W options (whenever
 they do not act solely as such, that is a bug)!
 
 There is a defined mechanism for user code to avoid some -pedantic
 warnings: use __extension__.  If you are counting a library as part of
 your application, and it does not meet your coding standards as to what
 warnings should be avoided, you will (in general) need to adapt it to meet
 your standards.
 
 Some warnings may not be avoidable by __extension__.  In future we hope to
 provide pragmas for fine-grained exclusion of specific warnings from
 specific lines of code (or from a whole translation unit); see the
 projects list.
 
 Some -pedantic warnings, for features now in C99, can also be avoided by
 using -std=gnu99.
 
 -- 
 Joseph S. Myers
 jsm28@cam.ac.uk
 

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

[Zack Weinberg]

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

From: "Zack Weinberg" <zackw@stanford.edu>
To: "Ronald F. Guilmette" <rfg@monkeys.com>
Cc: "Joseph S. Myers" <jsm28@cam.ac.uk>, 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 14:07:38 -0700

 On Sat, Apr 28, 2001 at 01:27:03PM -0700, Ronald F. Guilmette wrote:
 > 
 > 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.
 
 In point of fact, GCC considers any header found in /usr/include or
 other specially designated place (at configuration time, or with
 -isystem) as a "system header."  GCC's idea of a "system header" does
 not match that found in the C standard.  It means only that all
 warnings (except those triggered by #warning) are suppressed.
 
 Whether or not this is the ideal behavior, I have no opinion.  I will
 point out, however, that a casual user of GCC likely does not have
 write access to /usr/include, so any warnings evoked by any header in
 there are equally irritating and equally unavoidable.
 
 Independently of this, I think that a __PEDANTIC__ predefine would be
 a good idea.  It's easy to add - just another chunk of line noise in
 gcc.c - and would be at least as useful as some of the predefines we
 already have.
 
 zw

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

[Ronald F. Guilmette]

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.
 

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

[Joseph S. Myers]

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

From: "Joseph S. Myers" <jsm28@cam.ac.uk>
To: <rfg@monkeys.com>
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 20:55:32 +0100 (BST)

 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.
 
 (You'll need to ensure that the glib headers do count as system headers,
 e.g. by adding
 
 #if defined(__GNUC__) && (__GNUC__ > 2 || __GNUC_MINOR >= 97)
 #pragma GCC system_header
 #endif
 
 .)
 
 -- 
 Joseph S. Myers
 jsm28@cam.ac.uk
 

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

[rfg]

>Number:         2677
>Category:       c
>Synopsis:       Need something to #ifdef on when -pedantic/-pedantic-errors
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Sat Apr 28 12:46:00 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator:     Ronald F. Guilmette
>Release:        gcc-2.95.2
>Organization:
>Environment:
Nothing special
>Description:
Both gcc and g++ really ought to cause the preprocessor (or
perhaps the front-end driver) to pre-define some special
preprocessor symbol (e.g. __PEDANTIC__) when and if either
the -pedantic or -pedantic-errors option is used.  This
would allow various include files supplied by various widely
used packages (e.g. glib) to properly conditionalize certain
parts of themselves in order to avoid compile-time warnings
and/or errors when -pedantic or -pedantic-errors is used
during compilation.  Note that it is currently impossible
(with gcc/g++) to properly conditionalize include files
so that they will be both (a) maximally efficient when
-pedantic/-pedantic-errors is NOT used and also (b) maximally
conformant with C/C++ language standards when the -pedantic
or -pedantic-errors options ARE used.
>How-To-Repeat:
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.
As noted in the description above, there is no way, at present
to properly conditionalize this include file so that it does
the Right Thing, either when -pedantic/-pedantic-errors is
used, or when it is not used.
>Fix:
This could be fixed either by having the preprocessor itself
defined some special new symbol (e.g. __PEDANTIC__) if and
only if it is passed the -pedantic or -pedantic-errors option,
or alternatively (and perhaps better) this could be hacked
into the gcc/g++ driver program, specifically into the
sub-task invocation "specs", as is already done in the case
of the -ansi option and the __STRICT_ANSI__ preprocessor
symbol.  (This would make the definition of this new symbol
visible when people invoke the compiler with -v.)
>Release-Note:
>Audit-Trail:
>Unformatted: