In message <20050921195915.681925287@fnord.ir.bbn.com>, Greg Troxel writes:
>not very relevant background: I have a project with -current on the
>vendor branch and extensive local changes.  We just did an
>import/merge and are cleaning up const/-Werror fallout.  Much of this
>is a good thing.
>
>In ieee80211_input, I made changes to attach an mtag with a signal
>strength indication, to later be able to deliver signal strength
>metadata to sockets a la IP_RECVIF.  I used the variable mtag, which
>does not appear in the text of the function.  After the merge I got a
>warning (error) about shadowed declarations, which I traced to
>VLAN_INPUT_TAG which declares mtag inside a do {}.
>
>Although I find many defects in code from compiler warnings, in
>stronger moments I try to be of the "write correct code the first
>time" school, as espoused by Watts Humphrey in _A Discipline For
>Software Engineering_ (the Personal Software Process).  Writing
>correct code without invoking the compiler would seem to require
>reading the source code of all macros, which seems more than a bit
>awkward.  As Alex said long ago, now we see the violence inherent in
>the (macro) system.
>
>Options are:
>
>  a) the kernel is one big program; tell people not to do what I did,
>  or to change my variable or the macro one to something else when
>  this happens (I'm going to rename my variable for now).

Not feasible, as you just learned the hard way.
>
>  b) use inline functions to get separation of namespaces between
>  functions and "macros" invoked from them.  This may go beyond C99
>  and thus be unacceptable.

Not a bad idea for new stuff.
>
>  c) use a restricted namespace for variables defined in macros,
>  calling this instead VLAN_INPUT_TAG_mtag so it won't clash (with
>  anyone who isn't asking for trouble).
>
This one should be a rule for anyone writing macros that are used 
outside of their own small code segment.  In my opinion, you should
file a PR on that macro; I consider it buggy.  (The owner of that code 
segment may have a different opinion....)

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb