Coccinelle archive on lore.kernel.org
 help / color / Atom feed
* [Cocci] Searching for exported Linux functions
@ 2020-05-01 11:43 Markus Elfring
       [not found] ` <alpine.DEB.2.21.2005011348250.2504@hadrien>
  0 siblings, 1 reply; 5+ messages in thread
From: Markus Elfring @ 2020-05-01 11:43 UTC (permalink / raw)
  To: Coccinelle

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Cocci] Searching for exported Linux functions
       [not found] ` <alpine.DEB.2.21.2005011348250.2504@hadrien>
@ 2020-05-01 12:36   ` Markus Elfring
  2020-05-02  5:56   ` [Cocci] Searching for global items in the source code Markus Elfring
  1 sibling, 0 replies; 5+ messages in thread
From: Markus Elfring @ 2020-05-01 12:36 UTC (permalink / raw)
  To: Julia Lawall; +Cc: Coccinelle

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Cocci] Searching for global items in the source code
       [not found] ` <alpine.DEB.2.21.2005011348250.2504@hadrien>
  2020-05-01 12:36   ` Markus Elfring
@ 2020-05-02  5:56   ` Markus Elfring
  2020-05-02  7:05     ` Julia Lawall
  1 sibling, 1 reply; 5+ messages in thread
From: Markus Elfring @ 2020-05-02  5:56 UTC (permalink / raw)
  To: Julia Lawall; +Cc: Coccinelle

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Cocci] Searching for global items in the source code
  2020-05-02  5:56   ` [Cocci] Searching for global items in the source code Markus Elfring
@ 2020-05-02  7:05     ` Julia Lawall
  2020-05-02  7:43       ` Markus Elfring
  0 siblings, 1 reply; 5+ messages in thread
From: Julia Lawall @ 2020-05-02  7:05 UTC (permalink / raw)
  To: Markus Elfring; +Cc: Coccinelle


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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Cocci] Searching for global items in the source code
  2020-05-02  7:05     ` Julia Lawall
@ 2020-05-02  7:43       ` Markus Elfring
  0 siblings, 0 replies; 5+ messages in thread
From: Markus Elfring @ 2020-05-02  7:43 UTC (permalink / raw)
  To: Julia Lawall; +Cc: Coccinelle

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, back to index

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-01 11:43 [Cocci] Searching for exported Linux functions Markus Elfring
     [not found] ` <alpine.DEB.2.21.2005011348250.2504@hadrien>
2020-05-01 12:36   ` Markus Elfring
2020-05-02  5:56   ` [Cocci] Searching for global items in the source code Markus Elfring
2020-05-02  7:05     ` Julia Lawall
2020-05-02  7:43       ` Markus Elfring

Coccinelle archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/cocci/0 cocci/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 cocci cocci/ https://lore.kernel.org/cocci \
		cocci@systeme.lip6.fr
	public-inbox-index cocci

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/fr.lip6.systeme.cocci


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git