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

[Yoann Padioleau]

Ali-Erdem OZCAN <ali-erdem.ozcan at st.com> writes:

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

My proposition in my last mail should handle this case and the
previous one.

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

I guess you mean you want the metavariable to be bound to 'prefix_foo'
(to really take into account the macro expansion semantics of METH).

> because a direct reference to
> foo' may appear later in the code without the use of the METH
> macro.

The code could perhaps be clearer if you would consistently use 
METH ...

> The same case applies for METHOD(foo,bar) since a direct
> reference to componentName_foo_bar may appear in the same source code,

Sure, but apparently right now your SP does not require
to match over those different places. You just want to 
be able to analyse code like:

 void METH(foo)(COMP_TYPE* this, int i){

with a SP like:
   @ rule1 @ 
   identifier fn;
   typedef COMP_TYPE;
   identifier this;
   @@
   void fn(
   -COMP_TYPE* this,
   ... ) {
    ...
   }

and you never use 'fn' later in your SP in a callsite position.
So right now to what 'fn' is binded does not really matter. What
matters is just to be able to parse and unparse code having
those elaborated idents.

> and spatch should detect that they both refer to the same thing.

Yes, later, ... let's start by just being able to parse it.

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