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

[rfg at monkeys dot com]

>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: