Re: [Cocci] __init macro and Coccinelle

2017-08-15 Thread Julia Lawall


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

2017-08-15 Thread Gustavo A. R. Silva

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

2017-08-15 Thread SF Markus Elfring
>> 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

2017-08-15 Thread Julia Lawall


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

2017-08-15 Thread SF Markus Elfring
> 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

2017-08-15 Thread SF Markus Elfring
>> * 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

2017-08-15 Thread Julia Lawall
> * 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

2017-08-15 Thread SF Markus Elfring
>> 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

2017-08-15 Thread Julia Lawall


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

2017-08-15 Thread SF Markus Elfring
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

2017-08-15 Thread SF Markus Elfring
> 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

2017-08-15 Thread Reshetova, Elena
> 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

2017-08-15 Thread Julia Lawall


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

2017-08-15 Thread SF Markus Elfring
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