Subject: shadowing of variables in macros considered hard to avoid
To: None <tech-net@netbsd.org>
From: Greg Troxel <gdt@netbsd.org>
List: tech-net
Date: 09/21/2005 15:59:15
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).

  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.

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