On Sat, 2 May 2020, Markus Elfring wrote:
> >> @display@
> >> identifier action;
> >> type return_type;
> >> @@
> >> *return_type action(...)
> >> {
> >> ...
> >> }
> >> EXPORT_SYMBOL(action);
> …
> > In this case, the problem entirely on your side. You should separate the
> > two top-level declarations into two separate rules, just like any other
> > two top-level declarations you would like to match.
>
> My SmPL script example affects the understanding of the software behaviour
> also around the following information.
> https://github.com/coccinelle/coccinelle/blob/a549b9f0a20e14fe9c36f45990b40dc5708ef8f2/docs/manual/cocci_syntax.tex#L1649
>
> “…
> All matching done by a SmPL rule is done intraprocedurally.
> …”
>
>
> * How are items represented from the global name space?
>
> * Would the interpretation of the situation be adjusted if a macro call
> and a function implementation would be moved into an other usage context
> like a C++ class (or an enclosing function implementation)?
I don't understand any of the above.
>
>
> > You also need a
> >
> > declarer name EXPORT_SYMBOL;
> >
> > in the rule that you need to create for matching that part of the code.
>
> Can it become interesting to match a macro call (or a similar
> annotation/attribute)
> also without the declaration of such a metavariable?
> https://github.com/coccinelle/coccinelle/blob/a549b9f0a20e14fe9c36f45990b40dc5708ef8f2/docs/manual/cocci_syntax.tex#L310
It has nothing to do with EXPORT_SYMBOL being a macro. The declaration is
needed to tell Coccinelle to look for the thing at top level. Otherwise
EXPORT_SYMBOL(...); looks like a function call.
julia_______________________________________________
Cocci mailing list
[email protected]
https://systeme.lip6.fr/mailman/listinfo/cocci
