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