Re: [Cocci] __init macro and Coccinelle
On Tue, 15 Aug 2017, Gustavo A. R. Silva wrote: > Hello everybody, > > I have the following script: > > @r@ > identifier f_init; > position p; > @@ > > > * __init f_init@p(...) > > I want to spot __init functions, but it doesn't seem to work. I get a parse > error around the __init macro: > > around = '__init', > whole content = * __init f_init@p(...) > > I wonder if there is a way to work around that issue? If you want to match a function, you have to put something that will match the whole function, not just the top part. So it would be __init f(...) { ... } julia ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
[Cocci] __init macro and Coccinelle
Hello everybody, I have the following script: @r@ identifier f_init; position p; @@ * __init f_init@p(...) I want to spot __init functions, but it doesn't seem to work. I get a parse error around the __init macro: around = '__init', whole content = * __init f_init@p(...) I wonder if there is a way to work around that issue? Thank you -- Gustavo A. R. Silva ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] Comparing statement lists with SmPL
>> Now I am looking for a way to express the constraint that the statement list >> metavariable should match only source code with two statements at least. >> Can the search for duplicated source code be improved by the means of the >> semantic patch language? > > For two statements at least you could do: > > ( > { > s1 > s2 > ... > } > & > { > sl > } > ) Thanks for another example. I admit that I am unused to such a variable combination with a SmPL conjunction. Will this programming interface evolve any further? Regards, Markus ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] Comparing statement lists with SmPL
On Tue, 15 Aug 2017, SF Markus Elfring wrote: > > The source code analysis results look promising by this command. > > I have just noticed that an other source file points details out for further > development considerations around the mentioned functionality from the > Coccinelle software. > > elfring@Sonne:~/Projekte/Linux/next-patched> git checkout next-20170803 && > spatch.opt ~/Projekte/Coccinelle/janitor/show_same_statements1.cocci > sound/pci/rme9652/hdspm.c > … > (ONCE) already tagged but only removed, so safe > diff = > … > @@ -6497,9 +6497,6 @@ static int snd_hdspm_create_alsa_devices > i = 0; > while (i < hdspm->midiPorts) { > err = snd_hdspm_create_midi(card, hdspm, i); > - if (err < 0) { > - return err; > - } > i++; > } > > @@ -6955,10 +6952,6 @@ static int snd_hdspm_probe(struct pci_de > hdspm->pci = pci; > > err = snd_hdspm_create(card, hdspm); > - if (err < 0) { > - snd_card_free(card); > - return err; > - } > > if (hdspm->io_type != MADIface) { > snprintf(card->shortname, sizeof(card->shortname), "%s_%x", > … > > > Now I am looking for a way to express the constraint that the statement list > metavariable should match only source code with two statements at least. > Can the search for duplicated source code be improved by the means of the > semantic patch language? For two statements at least you could do: ( { s1 s2 ... } & { sl } ) julia___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] Comparing statement lists with SmPL
> The source code analysis results look promising by this command. I have just noticed that an other source file points details out for further development considerations around the mentioned functionality from the Coccinelle software. elfring@Sonne:~/Projekte/Linux/next-patched> git checkout next-20170803 && spatch.opt ~/Projekte/Coccinelle/janitor/show_same_statements1.cocci sound/pci/rme9652/hdspm.c … (ONCE) already tagged but only removed, so safe diff = … @@ -6497,9 +6497,6 @@ static int snd_hdspm_create_alsa_devices i = 0; while (i < hdspm->midiPorts) { err = snd_hdspm_create_midi(card, hdspm, i); - if (err < 0) { - return err; - } i++; } @@ -6955,10 +6952,6 @@ static int snd_hdspm_probe(struct pci_de hdspm->pci = pci; err = snd_hdspm_create(card, hdspm); - if (err < 0) { - snd_card_free(card); - return err; - } if (hdspm->io_type != MADIface) { snprintf(card->shortname, sizeof(card->shortname), "%s_%x", … Now I am looking for a way to express the constraint that the statement list metavariable should match only source code with two statements at least. Can the search for duplicated source code be improved by the means of the semantic patch language? Regards, Markus ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] Comparing statement lists with SmPL
>> * How can be determined how many code is equivalent between two statement >> list variables? > > I guess you can make special cases, for one statement, two statements, etc. I guess that we would like to avoid such an approach for some use cases. I hope that there are safer programming possibilities available. Regards, Markus ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] Comparing statement lists with SmPL
> * How can be determined how many code is equivalent between two statement > list variables? I guess you can make special cases, for one statement, two statements, etc. julia ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] Comparing statement lists with SmPL
>> Is this programming interface usable to determine if any code could be >> combined >> to some degree? > > I don't really understand the questions. I try again to describe the use case I became interested in a bit more. > Statement list metavariables can be used once they are bound like any other > metavariables. Can it be that they will need any special computing power occasionally? I have tried the following small SmPL script out. @duplicated_code@ identifier work; statement list sl; type T; @@ T work(...) { ... when any *if ((...) < 0) { * sl *} ... *if ((...) < 0) { * sl *} ... } The source code analysis results look promising by this command. elfring@Sonne:~/Projekte/Linux/next-patched> git checkout next-20170803 && spatch.opt ~/Projekte/Coccinelle/janitor/show_same_statements1.cocci sound/pci/rme9652/hdsp.c … @@ -793,11 +793,6 @@ static int hdsp_get_iobox_version (struc … @@ -5382,19 +5372,11 @@ static int snd_hdsp_probe(struct pci_dev … How should such update candidates be transformed further? > However they can only be bound to the complete sequence of statements in a > block. So > > @@ > statement list sl; > @@ > if (x) { > sl > } > > is ok, but > > @@ > statement list sl; > @@ > if (x) { > one(); > sl > two(); > } > > is not. Thanks for your example. * I do not like the mentioned software restriction at the moment. * How can be determined how many code is equivalent between two statement list variables? Regards, Markus ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] Comparing statement lists with SmPL
On Tue, 15 Aug 2017, SF Markus Elfring wrote: > Hello, > > The Coccinelle software supports metavariables with the type “statement list”. > Can statement lists be compared if they refer to the same source code > structures? > Is this programming interface usable to determine if any code could be > combined > to some degree? I don't really understand the questions. Statement list metavariables can be used once they are bound like any other metavariables. However they can only be bound to the complete sequence of statements in a block. So @@ statement list sl; @@ if (x) { sl } is ok, but @@ statement list sl; @@ if (x) { one(); sl two(); } is not. julia > > Regards, > Markus > ___ > Cocci mailing list > Cocci@systeme.lip6.fr > https://systeme.lip6.fr/mailman/listinfo/cocci >___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
[Cocci] Comparing statement lists with SmPL
Hello, The Coccinelle software supports metavariables with the type “statement list”. Can statement lists be compared if they refer to the same source code structures? Is this programming interface usable to determine if any code could be combined to some degree? Regards, Markus ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] Coccinelle: add atomic_as_refcounter script
> Elena, please don't follow Markus's suggestion. I suggest to consider additional software development possibilities. We have got recurring different opinions around the application of advanced regular expressions. > Coccinelle doesn't interpret regular expressions when selecting code to work > on, This software behaviour can be fine. > and thus the resulting rule will be less efficient. I do not come to the same conclusion for some use cases. > Markus, if you see this somehow, Yes. - But I can read your response only by the web interface for your mailing list archive at the moment. https://systeme.lip6.fr/pipermail/cocci/2017-August/004308.html > at least yesterday all mail sent to you was bouncing. Thanks for this information. - I was not informed about such message exchange problems so far. I hope that communication difficulties will be fixed somehow. Regards, Markus ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] [PATCH] Coccinelle: add atomic_as_refcounter script
> On Mon, 14 Aug 2017, Elena Reshetova wrote: > > > atomic_as_refcounter.cocci script allows detecting > > cases when refcount_t type and API should be used > > instead of atomic_t. > > > > Signed-off-by: Elena Reshetova> > --- > > scripts/coccinelle/api/atomic_as_refcounter.cocci | 148 > ++ > > 1 file changed, 148 insertions(+) > > create mode 100644 scripts/coccinelle/api/atomic_as_refcounter.cocci > > > > diff --git a/scripts/coccinelle/api/atomic_as_refcounter.cocci > b/scripts/coccinelle/api/atomic_as_refcounter.cocci > > new file mode 100644 > > index 000..996d72b > > --- /dev/null > > +++ b/scripts/coccinelle/api/atomic_as_refcounter.cocci > > @@ -0,0 +1,148 @@ > > +// Check if refcount_t type and API should be used > > +// instead of atomic_t type when dealing with refcounters > > +// > > +// Copyright (c) 2016-2017, Elena Reshetova, Intel Corporation > > +// > > +// Confidence: Moderate > > +// URL: http://coccinelle.lip6.fr/ > > +// Options: --include-headers --very-quiet > > + > > +virtual report > > + > > +@r1 exists@ > > +identifier a, x, y; > > +position p1, p2; > > +identifier fname =~ ".*free.*"; > > +identifier fname2 =~ ".*destroy.*"; > > +identifier fname3 =~ ".*del.*"; > > +identifier fname4 =~ ".*queue_work.*"; > > +identifier fname5 =~ ".*schedule_work.*"; > > +identifier fname6 =~ ".*call_rcu.*"; > > + > > +@@ > > + > > +( > > + atomic_dec_and_test@p1(&(a)->x) > > +| > > + atomic_dec_and_lock@p1(&(a)->x, ...) > > +| > > + atomic_long_dec_and_lock@p1(&(a)->x, ...) > > +| > > + atomic_long_dec_and_test@p1(&(a)->x) > > +| > > + atomic64_dec_and_test@p1(&(a)->x) > > +| > > + local_dec_and_test@p1(&(a)->x) > > +) > > +... > > +( > > + fname@p2(a, ...); > > +| > > + fname2@p2(...); > > +| > > + fname3@p2(...); > > +| > > + fname4@p2(...); > > +| > > + fname5@p2(...); > > +| > > + fname6@p2(...); > > +) > > + > > + > > +@script:python depends on report@ > > +p1 << r1.p1; > > +p2 << r1.p2; > > +@@ > > +msg = "atomic_dec_and_test variation before object free at line %s." > > +coccilib.report.print_report(p1[0], msg % (p2[0].line)) > > + > > +@r4 exists@ > > +identifier a, x, y; > > +position p1, p2; > > +identifier fname =~ ".*free.*"; > > +identifier fname2 =~ ".*destroy.*"; > > +identifier fname3 =~ ".*del.*"; > > +identifier fname4 =~ ".*queue_work.*"; > > +identifier fname5 =~ ".*schedule_work.*"; > > +identifier fname6 =~ ".*call_rcu.*"; > > + > > +@@ > > + > > +( > > + atomic_dec_and_test@p1(&(a)->x) > > +| > > + atomic_dec_and_lock@p1(&(a)->x, ...) > > +| > > + atomic_long_dec_and_lock@p1(&(a)->x, ...) > > +| > > + atomic_long_dec_and_test@p1(&(a)->x) > > +| > > + atomic64_dec_and_test@p1(&(a)->x) > > +| > > + local_dec_and_test@p1(&(a)->x) > > +) > > +... > > +y=a > > +... > > +( > > + fname@p2(y, ...); > > +| > > + fname2@p2(...); > > From here to the end of the rule there is no a or y. So they would match > the same thing as in the previous rule. so you could get rid of all of > these cases, and just leave fname@p2(y, ...); True, stupid of me :( Will fix. Best Regards, Elena. > > julia > > > +| > > + fname3@p2(...); > > +| > > + fname4@p2(...); > > +| > > + fname5@p2(...); > > +| > > + fname6@p2(...); > > +) > > + > > + > > +@script:python depends on report@ > > +p1 << r4.p1; > > +p2 << r4.p2; > > +@@ > > +msg = "atomic_dec_and_test variation before object free at line %s." > > +coccilib.report.print_report(p1[0], msg % (p2[0].line)) > > + > > +@r2 exists@ > > +identifier a, x; > > +position p1; > > +@@ > > + > > +( > > +atomic_add_unless(&(a)->x,-1,1)@p1 > > +| > > +atomic_long_add_unless(&(a)->x,-1,1)@p1 > > +| > > +atomic64_add_unless(&(a)->x,-1,1)@p1 > > +) > > + > > +@script:python depends on report@ > > +p1 << r2.p1; > > +@@ > > +msg = "atomic_add_unless" > > +coccilib.report.print_report(p1[0], msg) > > + > > +@r3 exists@ > > +identifier x; > > +position p1; > > +@@ > > + > > +( > > +x = atomic_add_return@p1(-1, ...); > > +| > > +x = atomic_long_add_return@p1(-1, ...); > > +| > > +x = atomic64_add_return@p1(-1, ...); > > +) > > + > > +@script:python depends on report@ > > +p1 << r3.p1; > > +@@ > > +msg = "x = atomic_add_return(-1, ...)" > > +coccilib.report.print_report(p1[0], msg) > > + > > + > > -- > > 2.7.4 > > > > ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] Coccinelle: add atomic_as_refcounter script
On Tue, 15 Aug 2017, SF Markus Elfring wrote: > Dear Elena, > > Would you like to take another look at my development suggestion for your > approach? > https://systeme.lip6.fr/pipermail/cocci/2017-August/004300.html > > How do you think about to refactor another rule like the following? > > @r3 exists@ > expression E; > identifier I=~"^atomic(?:64|_long)?_add_return$"; > position P; > @@ > E = I@P(-1, ...); > > > Can the specification of SmPL constraints be occasionally be more succinct > with the use of regular expressions? Elena, please don't follow Markus's suggestion. Coccinelle doesn't interpret regular expressions when selecting code to work on, and thus the resulting rule will be less efficient. Markus, if you see this somehow, at least yesterday all mail sent to you was bouncing. julia ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] Coccinelle: add atomic_as_refcounter script
Dear Elena, Would you like to take another look at my development suggestion for your approach? https://systeme.lip6.fr/pipermail/cocci/2017-August/004300.html How do you think about to refactor another rule like the following? @r3 exists@ expression E; identifier I=~"^atomic(?:64|_long)?_add_return$"; position P; @@ E = I@P(-1, ...); Can the specification of SmPL constraints be occasionally be more succinct with the use of regular expressions? Regards, Markus ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci