* [Cocci] Coccinelle question @ 2013-04-24 10:03 Majid Java 2013-04-29 2:52 ` Julia Lawall 0 siblings, 1 reply; 4+ messages in thread From: Majid Java @ 2013-04-24 10:03 UTC (permalink / raw) To: cocci Hello, last night i saw your website and projects from google search im really interested in what Coccinelle doing as i understand its kind of open source c parser library that follow in source code for variables and trace all source and headers for it,Right? now i have some questions: Are you take care of Variable Scopes when you are searching the source code? Thanks -- <Http://m4jid2k.Cjb.Net> -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://systeme.lip6.fr/pipermail/cocci/attachments/20130424/05e0eb6d/attachment.html> ^ permalink raw reply [flat|nested] 4+ messages in thread
* [Cocci] Coccinelle question 2013-04-24 10:03 [Cocci] Coccinelle question Majid Java @ 2013-04-29 2:52 ` Julia Lawall 0 siblings, 0 replies; 4+ messages in thread From: Julia Lawall @ 2013-04-29 2:52 UTC (permalink / raw) To: cocci On Wed, 24 Apr 2013, Majid Java wrote: > Hello, > > last night i saw your website and projects from google search im really > interested in what Coccinelle doing as i understand its kind of open source > c parser library that follow in source code for variables and trace all > source and headers for it,Right? Specific points are that it follows the control-flow graph, via the ... operator, it lets you match against metavariables that accumulate properties from other matches, so you can make generic specifications, and it is (mostly) aware of type information. > now i have some questions: > Are you take care of Variable Scopes when you are searching the source code? Only somewhat. Within a given rule, links to where C variables are bound are taken into account. But when a metavariable is inherited from one rule to the next, all of this information is dropped. This is in part because Coccinelle supports transformation as well as matching, and you could transform the variable declaration itself. For example, you could decide that you don't like variables being declared in the branches of an if statement, and move the declarations up to top level. The same variables are still attached to the same binder, but by the way Coccinelle is constructed (added code is not really interpreted) it would be hard to detect this. This may seem like a bug, but in practice, at least on Linux code, it can be more of a feature. Linux code often uses the same variable name for the same conceptual quantity throughout a file, so it can be a way to find all of the treatment of a particular value even when in the given file there is no explicit interprocedural control-flow from one function using the value to another. Of course the result is not safe, but someone looking at the result may have enough expertise to know that the right thing is being done. If you have further questions please feel free to write back. If you join the mailing list, you will get a faster response. Thank you for your interest in Coccinelle. julia ^ permalink raw reply [flat|nested] 4+ messages in thread
[parent not found: <83363fd9-a6b1-28be-e0a7-168f205cb551@student.ethz.ch>]
[parent not found: <9c5ba524fec340a9c6ea8809e93ee0e8@lip6.fr>]
* Re: [Cocci] Coccinelle question [not found] ` <9c5ba524fec340a9c6ea8809e93ee0e8@lip6.fr> @ 2019-05-08 14:42 ` Nicolas Koenig 2019-05-09 7:13 ` Julia Lawall 0 siblings, 1 reply; 4+ messages in thread From: Nicolas Koenig @ 2019-05-08 14:42 UTC (permalink / raw) To: Julia Lawall, cocci; +Cc: seth.arnold Hello Julia, world, Thank you for the quick reply On 08/05/2019 14:10, Julia Lawall wrote: > Le 08.05.2019 12:15, Nicolas Koenig a écrit : >> Hi Julia, >> >> I've recently started to learn about cocinelle, but I have a few >> questions I can't for the life of me find the answers to in the >> documentation, so I hope that you (as one of the persons working on >> coccinelle) might be able to help. >> >> I'm trying to write a small script that replaces each return value >> with an argument of the same type. This requires special-casing >> functions that don't take arguments, so I looked at the following >> example I found in the official documentation >> >> @@ >> expression E,f; >> @@ >> ( >> if (<+... f(...) ...+>) { BUG(); } >> | >> - if (E) { BUG(); } >> + BUG_ON(E); >> ) >> >> and tried to adapt it, so that it (for the moment) just ignores >> functions without arguments >> >> @@ >> type T; >> identifier F; >> @@ >> ( >> int F ( void ) { ... } >> | >> - T >> + void >> F ( >> + T *ret, >> ... ) { ... } >> ) >> >> This yields a syntax error, though >> >> init_defs_builtins: /usr/lib/coccinelle/standard.h >> 35 36 >> Fatal error: exception Failure("minus: parse error: \n = File >> \"test1.cocci\", line 6, column 4, charpos = 35\n around = 'F', >> whole content = int F ( void ) { ... }\n") >> >> Any hint what I'm doing wrong would help. Also, what are in general >> the rules for the '( | )' syntax? > > I'm not sure whether you can make a disjunction for a function > definition. It seems to work for forward function declarartions, just not for declarations with implementation attached @@ type T; identifier fn; @@ ( T xyzzy(...); | - T fn + void fn (...); ) works as expected, while @@ type T; identifier fn; @@ ( T xyzzy(...) {...} | - T fn + void fn (...) {...} ) yields a parser error. > But I don't think that a function with just void as a > parameter list will match what you have in the other disjunct, so I > think you can just get rid of the void case. It seem to match. Running the following little patch/script @@ type T; identifier fn; @@ - T fn( + void fn(T *ret, ...) {...} generates, for example, the following diff -int foo(void) { +void foo(int *ret, void) { return 0; } Any idea what the best way to prevent this would be? > >> Thank you in advance! >> >> Nicolas >> >> P.S.: Is there a community where I can ask such questions without >> bothering people personally? > > Yes, there is a mailing list., You should see this in the contact link > at coccinelle.lip6.fr. You should join the mailing list so I don't have > to approve the posts. Thank you, I've subscribed and added the list to this thread Nicolas > > julia _______________________________________________ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Cocci] Coccinelle question 2019-05-08 14:42 ` Nicolas Koenig @ 2019-05-09 7:13 ` Julia Lawall 0 siblings, 0 replies; 4+ messages in thread From: Julia Lawall @ 2019-05-09 7:13 UTC (permalink / raw) To: Nicolas Koenig; +Cc: seth.arnold, cocci > It seem to match. Running the following little patch/script > > @@ > type T; > identifier fn; > @@ > > - T fn( > + void fn(T *ret, > ...) {...} > > generates, for example, the following diff > > -int foo(void) { > +void foo(int *ret, void) { > return 0; > } > > Any idea what the best way to prevent this would be? OK, sorry, I didn't notice that it was only ... in the matching part. I think you could just put a dummy parameter: @@ type T,T1; identifier fn,i; @@ - T fn( + void fn(T *ret, T1 i, ...) {...} That should match cases with only one parameter, even though the , doesn't match anything. julia >> >>> Thank you in advance! >>> >>> Nicolas >>> >>> P.S.: Is there a community where I can ask such questions without >>> bothering people personally? >> >> Yes, there is a mailing list., You should see this in the contact >> link at coccinelle.lip6.fr. You should join the mailing list so I >> don't have to approve the posts. > > Thank you, I've subscribed and added the list to this thread > > Nicolas > >> >> julia _______________________________________________ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2019-05-09 7:14 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-04-24 10:03 [Cocci] Coccinelle question Majid Java 2013-04-29 2:52 ` Julia Lawall [not found] <83363fd9-a6b1-28be-e0a7-168f205cb551@student.ethz.ch> [not found] ` <9c5ba524fec340a9c6ea8809e93ee0e8@lip6.fr> 2019-05-08 14:42 ` Nicolas Koenig 2019-05-09 7:13 ` Julia Lawall
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).