[Cocci] Searching for exported Linux functions

[Cocci] Searching for exported Linux functions

[Markus Elfring]

Hello,

I would like to determine specific information also by the means of another
script for the semantic patch language.


@display@
identifier action;
type return_type;
@@
*return_type action(...)
 {
 ...
 }
 EXPORT_SYMBOL(action);


But I get the following error message so far.

elfring@Sonne:~/Projekte/Coccinelle/janitor> spatch --parse-cocci show_exported_functions1.cocci
…
minus: parse error:
  File "show_exported_functions1.cocci", line 9, column 1, charpos = 87
  around = 'EXPORT_SYMBOL',
  whole content =  EXPORT_SYMBOL(action);


How are the chances for further software evolution according to such
a data processing approach?

Regards,
Markus
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Searching for exported Linux functions

[Markus Elfring]

>> @display@
>> identifier action;
>> type return_type;
>> @@
>> *return_type action(...)
>>  {
>>  ...
>>  }
>>  EXPORT_SYMBOL(action);
>>
>>
>> But I get the following error message so far.
>>
>> elfring@Sonne:~/Projekte/Coccinelle/janitor> spatch --parse-cocci show_exported_functions1.cocci
>> …
>> minus: parse error:
>>   File "show_exported_functions1.cocci", line 9, column 1, charpos = 87
>>   around = 'EXPORT_SYMBOL',
>>   whole content =  EXPORT_SYMBOL(action);
>>
>>
>> How are the chances for further software evolution according to such
>> a data processing approach?
>
> Do you have any idea how annoying this comment is?

It seems that we come along different possible interpretations
also for this clarification request.


> Basically, you are saying "I'm surprised about the result,

* My surprise is limited here.

* I have contributed another software test result.


> so someone else should go fix the system so it does what I think it should do".

Improvements will depend on corresponding development resources.


> Couldn't you express yourself as "What should I do to get the result I expect?".

I usually try to inform contributors about change possibilities.


> That is, put the burden on yourself, rather than shifting it
> immediately to someone else.

It is interesting that you interpret my bug report (or feature request)
in this direction.


> In this case, the problem entirely on your side.

I have got an other impression.


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

I can take additional alternatives into account after the failure of
a direct approach.


> You also need a
>
> declarer name EXPORT_SYMBOL;
>
> in the rule that you need to create for matching that part of the code.

Thanks for this information.


@find@
declarer name EXPORT_SYMBOL;
identifier action;
@@
 EXPORT_SYMBOL(action);

@display@
identifier find.action;
type return_type;
@@
*return_type action(...)
 {
 ...
 }


Would it be nicer if a single SmPL rule will be sufficient instead?

Regards,
Markus
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Searching for global items in the source code

[Markus Elfring]

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


> 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

Regards,
Markus
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Searching for global items in the source code

[Julia Lawall]

[-- Attachment #1: Type: text/plain, Size: 1671 bytes --]



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

[-- Attachment #2: Type: text/plain, Size: 136 bytes --]

_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Searching for global items in the source code

[Markus Elfring]

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

I find such feedback also interesting somehow.

1. How will we achieve a better common understanding once more in this area?

2. It seems that you prefer so far to refer to “top-level” items instead of
   thinking with relationships to name spaces.

3. Can you imagine consequences according to nested function implementations?

4. The Coccinelle software contains limitations according to intraprocedural
   data processing.
   Under which circumstances will the application of interprocedural source
   code analysis increase?


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

Will it become helpful to add such an information also to the SmPL manual?
Can the software documentation become clearer another bit
also at this place?


> Otherwise EXPORT_SYMBOL(...); looks like a function call.

Function-like macros are just looking so similar.

Regards,
Markus
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci