[Cocci] Problem when using a macro for mangling function names

[Ali-Erdem OZCAN]

Julia Lawall wrote:
> On Fri, 20 Mar 2009, Ali-Erdem OZCAN wrote:
>
>   
>> Hi Julia and Yoann,
>>
>> Thanks for your reactivity.
>>
>> Indeed I already tried to add my macro using the macro_file option before I
>> sent you my e-mail yesterday. This works well with the example that I sent you
>> yesterday (I did not check it before sending, sorry), but unfortunately
>> doesn't work with my real use-case. For that reason, I send you now the files
>> on which I am working without trying to minimize them.
>>
>> The output that I have from spatch for these files is
>> ''spatch -macro_file macros.h -sp_file mind.cocci.bug mind.c.bug"
>> --------------------------------------
>> HANDLING: mind.c.bug
>> warning: line 30: should c1 be a metavariable?
>> Fatal error: exception Assert_failure("unparse_c.ml", 281, 8)
>> --------------------------------------
>> This error doesn't appear if I replace 'METH(foo)' by 'foo'.
>>
>> If I remove the last patch statement that uses 'c1' (the case which seems to
>> be the source of the problem regarding the error message) the output that I
>> have is:
>> ---------------------------------------
>> HANDLING: mind.c
>> Fatal error: exception Assert_failure("unparse_c.ml", 281, 8)
>> ---------------------------------------
>>     
>
> The problem is that it is not allowed to bind a metavariable to the result 
> of expanding a macro.  The error message is indeed not very graceful.  The 
> problem though is that the metavariable is bound to foo, not METH(foo), 
> and would thus match the wrong thing in your later rules, so just getting 
> rid of the assert would not really solve the problem.
>   
So if my understanding is good, spatch doesn't really expand the macros, 
it only extends the parsing rules to take them into account. Am I right ?
> I will try to find a way to solve the problem.  Is this pattern very 
> common in the code you are working with?
>   
Unfortunately yes. This is something that we cannot get rid of.
Moreover, another pattern which is very common is
#define METHOD(foo, bar) componentName_##foo##_##bar

I think this may raise other problems since
1. void METHOD(foor,bar)(params) is not valid C code as opposed to void 
METH(foo)(params) - as highlighted by Yoann.
2. if the macro expansion semantics is not took into account (hypothesis 
that might be wrong depending on the answer of my above question), then 
the metavariable could be bound to something wrong. Indeed, I believe 
that the metavariable should be bound to 'foo' (in the above case) and 
not to METH(foo) because a direct reference to 'foo' may appear later in 
the code without the use of the METH macro.The same case applies for 
METHOD(foo,bar) since a direct reference to componentName_foo_bar may 
appear in the same source code, and spatch should detect that they both 
refer to the same thing.

I am not sure if I am clear enough in my explanation, please don't 
hesitate to ask me more if it is not the case.

Erdem
> julia
>