On Fri, Nov 19, 2010 at 07:12:35AM +1000, Sunny Bains wrote:
>Kevin,
>
>On 19/11/2010, at 6:30 AM, Marko Mäkelä <marko.makela@stripped>
>wrote:
>
>>On Thu, Nov 18, 2010 at 09:39:15AM -0600, Kevin Lewis wrote:
>>>Most of the code I have worked on in the past used extra '-'
>>>before macro variables and sometimes after. Older preprocessors
>>>did not enforce the scope of those variables. They used to let
>>>all variables take on the scope of the code they happen to be
>>>dropped into.
>>
>>I am not aware of such preprocessors, and I have used various C
>>development environments since 1991 or so.
>>
>>Could you be thinking of variables that are introduced in the macro
>>expansion? There are a few such variables in the InnoDB code base,
>>in some data structure iterators. Heikki has used the 313 suffix
>>for them, and the <valgrind/memcheck.h> uses the _qzz prefix,
>>probably because it must try harder to avoid clashes.
>>
>>Some 10 years ago, I wrote a translator that generated C code. I
>>used the i prefix for some generated functions, which turned out to
>>be a bad idea: i386 was a reserved symbol in the default GCC
>>configuration.
>>
>> Marko
>
>I'm not sure which variables you are referring to.
ut_list_node_313, defined in the macro expansions in ut0lst.h. The
variable is declared in its own scope, so it would shadow any variable
definition by the same name in the outer scope.
Again, this is just my guess what Kevin might have thought of. To my
understanding, the cpp macro parameters are always 'local' to the macro
invocation: any occurrence of the parameter names within the macro body
will be replaced with what is passed in the macro invocation. You can
have
{
int a, b, c, d;
#define macro(a,b) a=b
macro(c,d);
}
and the variables a,b will be unaffected by the macro invocation.
Marko
