* [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[parent not found: <alpine.DEB.2.21.2005011348250.2504@hadrien>]
* 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, other threads:[~2020-05-02 7:44 UTC | newest]
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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).