Re: [PATCH][RFC] -Wno-... option to suppress builtin macro redefined warnings

[Simon Baldwin <simonb@google.com>]

Tom Tromey wrote:
>>>>>> "Simon" == Simon Baldwin <simonb@google.com> writes:
>>>>>>             
>
> ...
> However, it seems to me that we would want to allow redefinition of
> some macros (__TIME__ et al) but not others (e.g., __LINE__).
>
> So, how about splitting builtin_array into two pieces (and just FYI,
> there's a comment above referring to "two tables" that should be
> changed) and then unconditionally setting NODE_WARN for one table but
> not the other?  Or, just adding a special case in the builtin
> definition loop for the BT_* constants we care to allow.
>   

Thank you for the note.

I guess that in general it just seems more, um, seamless to either allow 
or disallow any builtin macro to be redefined.  It means that there's no 
"is it redefinable or not?" decision to be made when new builtins are 
added.  It also neatly sidesteps the issue of then having to document 
which builtins are redefinable and which aren't (also no update to this 
doc should new builtins be added), or having to deal with requests to 
move builtins between redefinable/fixed groups.  In other words, the 
lowest impact on future code maintainers consistent with low impact on 
current code.

Granted, somebody could well redefine __LINE__ or similar and make a 
mess of compilation, but there are of course plenty of other ways to 
make a mess of compilation with other gcc flags.  
-Wno-builtin-macro-redefined is aimed at the control-freak automated 
build system rather than the casual user, so it seemed okay, to me 
anyway, for it to bear closer resemblance to a chainsaw than to a scalpel.

That said, I'm not wildly opposed to creating two "classes" of builtin.  
It just seems like doing so might sow slightly more confusion than it 
prevents.

--S