------- Comment #2 from joseph at codesourcery dot com  2008-08-07 12:04 -------
Subject: Re:  -Wc++-compat refinements

On Thu, 7 Aug 2008, manu at gcc dot gnu dot org wrote:

> To clarify how to implement this, I have some questions:
> 
> (In reply to comment #0)
> > -Wc++-compat should allow bool, wchar_t, char16_t and char32_t as typedefs
> > defined in system headers, while warning if they are used other than as 
> > types
> > or the typedefs are defined other than in system headers.
> 
> This will require:
> 
> * a check in CPP when defining new macros. It should probably allow also to be
> used as macro name if defined in system header (#define bool _Bool).

I see no need for macro checks for these type names; the check should be 
for when they reach the C parser as identifiers, just like the checks for 
other C++ keywords both with the restriction on context.  Because they are 
keywords in C++, C++ programs could also define them as macros.

> > -Wc++-compat should warn for asm and inline when used in a C mode where they
> > are identifiers not keywords, but not in a mode when they are keywords and
> > not for the __ variants in any case.
> 
> I think that not checking the __ variants is given. I don't understand what 
> you
> mean by "not in a mode when they are keywords". My understanding is that we
> should warn always that they are used as names (type names, identifiers, macro
> names, macro parameters) and never when they are keywords (independently of 
> the
> C mode).

With -std=c89 -Wc++-compat, both are identifiers and both should be warned 
for when they reach the C parser as identifiers.  No warnings for 
preprocessor uses are needed.

With -std=gnu89 -Wc++-compat, both are keywords and neither should be 
warned for.

With -std=c99 -Wc++-compat, inline is a keyword and should not be warned 
for, but asm is an identifier and should be warned for.

> > -Wc++-compat should warn for uses of the alternative representations for
> > operators and punctuators such as "and", including uses as macro names 
> > (except
> > when defined in system headers, because of iso646.h) and macro parameter 
> > names.
> 
> Hence:
> 
> * a check in CPP when defining new macros.
> 
> * various checks in c-parser.c or c-decl.c to check for names. Any use here is
> wrong. (CPP would have already replaced 'and' if it is a macro).

That seems right.  If they reach the parser they can probably be handled 
just like the existing -Wc++-compat warnings (put in the keyword table for 
warning, but never actually handled as keywords), but additional 
preprocessor checks are needed as well.  (The relevant preprocessor cases 
give errors in C++.)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37041

Reply via email to