cocci.inria.fr archive mirror
 help / color / mirror / Atom feed
* 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   ` [Cocci] Coccinelle question 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

* [Cocci] Coccinelle question
  2013-04-24 10:03 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

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

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 --
     [not found] <83363fd9-a6b1-28be-e0a7-168f205cb551@student.ethz.ch>
     [not found] ` <9c5ba524fec340a9c6ea8809e93ee0e8@lip6.fr>
2019-05-08 14:42   ` [Cocci] Coccinelle question Nicolas Koenig
2019-05-09  7:13     ` Julia Lawall
2013-04-24 10:03 Majid Java
2013-04-29  2:52 ` 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).