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