Re: [Cocci] a small nuisance report

[Robert Larice]

Julia Lawall <julia.law...@lip6.fr> writes:

> On Sun, 29 Apr 2018, Robert Larice wrote:
>
>> Julia Lawall <julia.law...@lip6.fr> writes:
>>
>> > On Sun, 29 Apr 2018, Robert Larice wrote:
>> >
>> >> Hello,
>> >>
>> >>   attached is a small example which
>> >> injects a statement and a comment.
>> >>
>> >>   It works well, but does'nt do exactly as wanted.
>> >>
>> >>   I get :
>> >>
>> >> +j /* comments are overrated */
>> >> +-= 3;
>> >>
>> >>   The comment popped up within the expression instead
>> >> of in front of it.
>> >>   no bug, but uggly.
>> >
>> > This problem is solve in the github version of Coccinelle.  The problem
>> > was because j was declared as a symbol.
>> >
>> > julia
>>
>> Thank You,
>>
>>   so I could work around by simply using an "identifier"
>> perhaps augmented with a regexp match.
>
> No, just pull from github and recompile.
>
> julia

just did, and it just works,
Thanks,
  Robert
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] a small nuisance report

[Robert Larice]

Julia Lawall <julia.law...@lip6.fr> writes:

> On Sun, 29 Apr 2018, Robert Larice wrote:
>
>> Hello,
>>
>>   attached is a small example which
>> injects a statement and a comment.
>>
>>   It works well, but does'nt do exactly as wanted.
>>
>>   I get :
>>
>> +j /* comments are overrated */
>> +-= 3;
>>
>>   The comment popped up within the expression instead
>> of in front of it.
>>   no bug, but uggly.
>
> This problem is solve in the github version of Coccinelle.  The problem
> was because j was declared as a symbol.
>
> julia

Thank You,

  so I could work around by simply using an "identifier"
perhaps augmented with a regexp match.

Best Regards,
  Robert
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] perhaps a bug

[Robert Larice]

Julia Lawall <julia.law...@lip6.fr> writes:

> On Sun, 29 Apr 2018, Robert Larice wrote:
>
>> Julia Lawall <julia.law...@lip6.fr> writes:
>>
>> > On Sun, 29 Apr 2018, Robert Larice wrote:
>> >
>> >> Julia Lawall <julia.law...@lip6.fr> writes:
>> >>
>> >> > On Sun, 29 Apr 2018, Robert Larice wrote:
>> >> >
>> >> >> Hello,
>> >> >>
>> >> >>   attached is a small example which does something strange
>> >> >> to a  "int i, j;" within a "#ifdef..."
>> >> >>   Perhaps this points to a bug in coccinelle,
>> >> >>   Would you please check ?
>> >> >
>> >> > Thanks for the report.  It looks like a bug.  But everything is fine if
>> >> > you removed the --defined BOO.
>> >> >
>> >> > julia
>> >>
>> >> Yes, in this example it works without this --defined announcement.
>> >>
>> >> I stumbled on this with something more complex, which for some
>> >>  reason I don't understand yet ignores a wanted transformation
>> >>  in a #ifdef..#endif, except if I add such a --defined.
>> >> Only then it honours my transformation, but fails with this bug.
>> >
>> > I don't think the --defined option has been tested much.  Perhaps without
>> > the --defined there is a parse error on the function.
>> >
>> > julia
>>
>> Hello Julia,
>>
>>   I've attached a ripped down example to show the behaviour
>> with regard to the #ifdef
>>   Without the --defined, nothing gets tranformed.
>>   I don't see a parsing problem so far.
>>   Perhaps you can have a look and get an idea why
>> here the --defined is important.
>>   I've seen other transformations where this was not necessairy.
>
> OK, thanks for the example.  It is indeed not a parsing problem.  When
> #ifdefs are reasonably well behaved, Coccinelle internally considers them
> to have a control-flow structure like an if - the code in the #ifdef might
> be there or it might not.  On the other hand your rule requires that there
> is exactly one i = 0 on each control-flow path through the loop.  If you
> just want to remove any that happen to exist, you can instead write:
>
> <...
> - i = 0;
> ...>
>
> This will also remove cases where there are multiple initializations of i
> to 0 within the loop.
>
> julia

Thank You for your helpfull description,

  in face of this I can well understand the why,
  and how to work around.

Best Regards,
  Robert
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] perhaps a bug

[Robert Larice]

Julia Lawall <julia.law...@lip6.fr> writes:

> On Sun, 29 Apr 2018, Robert Larice wrote:
>
>> Julia Lawall <julia.law...@lip6.fr> writes:
>>
>> > On Sun, 29 Apr 2018, Robert Larice wrote:
>> >
>> >> Hello,
>> >>
>> >>   attached is a small example which does something strange
>> >> to a  "int i, j;" within a "#ifdef..."
>> >>   Perhaps this points to a bug in coccinelle,
>> >>   Would you please check ?
>> >
>> > Thanks for the report.  It looks like a bug.  But everything is fine if
>> > you removed the --defined BOO.
>> >
>> > julia
>>
>> Yes, in this example it works without this --defined announcement.
>>
>> I stumbled on this with something more complex, which for some
>>  reason I don't understand yet ignores a wanted transformation
>>  in a #ifdef..#endif, except if I add such a --defined.
>> Only then it honours my transformation, but fails with this bug.
>
> I don't think the --defined option has been tested much.  Perhaps without
> the --defined there is a parse error on the function.
>
> julia

Hello Julia,

  I've attached a ripped down example to show the behaviour
with regard to the #ifdef
  Without the --defined, nothing gets tranformed.
  I don't see a parsing problem so far.
  Perhaps you can have a look and get an idea why
here the --defined is important.
  I've seen other transformations where this was not necessairy.

Best Regards,
  Robert

// (compile "spatch --sp-file ex3.cocci ex3.c")
// (compile "spatch --sp-file ex3.cocci ex3.c --defined BOO")
// (compile "gcc -c -Wall ex3.c")

#define BOO

struct model;
struct model *next(struct model *);

void
foo(struct model *model)
{
#ifdef BOO
int i, j;
#endif

for (; model; model = next(model)) {
#ifdef BOO
i = 0;
#endif
j += 3;
}
}
// (compile "spatch --sp-file ex3.cocci ex3.c")
// (compile "spatch --sp-file ex3.cocci ex3.c --defined BOO")

@r0@
symbol model, i;
@@
-  int i;
   ...
   for(; model; model = ...) {
 ...
-i = 0;  
 ...
   }


___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

[Cocci] a small nuisance report

[Robert Larice]

Hello,

  attached is a small example which
injects a statement and a comment.

  It works well, but does'nt do exactly as wanted.

  I get :

+j /* comments are overrated */
+-= 3;

  The comment popped up within the expression instead
of in front of it.
  no bug, but uggly.

Regards,
  Robert

int foo(int bar)
{
  int i, j;
  for (i = 5; --i>=0; ) {
j+=54;
  }
  return j;
}

// (compile "spatch --sp-file ex2.cocci ex2.c")

@r0@
symbol j;
@@
  {
+   /* comments are overrated */   
+   j -= 3;
j += 54;
...
  }
 

___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] perhaps a bug

[Robert Larice]

Julia Lawall <julia.law...@lip6.fr> writes:

> On Sun, 29 Apr 2018, Robert Larice wrote:
>
>> Hello,
>>
>>   attached is a small example which does something strange
>> to a  "int i, j;" within a "#ifdef..."
>>   Perhaps this points to a bug in coccinelle,
>>   Would you please check ?
>
> Thanks for the report.  It looks like a bug.  But everything is fine if
> you removed the --defined BOO.
>
> julia

Yes, in this example it works without this --defined announcement.

I stumbled on this with something more complex, which for some
 reason I don't understand yet ignores a wanted transformation
 in a #ifdef..#endif, except if I add such a --defined.
Only then it honours my transformation, but fails with this bug.

I certainly will try to work around somehow.

Regards,
  Robert
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

[Cocci] perhaps a bug

[Robert Larice]

Hello,

  attached is a small example which does something strange
to a  "int i, j;" within a "#ifdef..."
  Perhaps this points to a bug in coccinelle,
  Would you please check ?

Best Regards,
  Robert

int foo(int bar)
{
  int i, j;

  return bar+54;
}


int boo(int bar)
{
#ifdef BOO
  int i, j;
#endif

  return bar+54;
}
// (compile "spatch --sp-file ex1.cocci ex1.c --defined BOO")

@r0@
symbol i;
@@
-  int i;
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

[Cocci] please help me with a "repetition"

[Robert Larice]

Hello,

  probably a stupid question,
  I'm failing to match something like this

+  int newvar;
   i++; i++; ... any sequence of only "i++";
+  buckbear(42);

  I don't succeed to express this "maximum length repetition"
in the mids of those two insertions.

Best Regards,
  Robert
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] might be bug report, breaking up of a comment

[Robert Larice]

Julia Lawall  writes:

> The problem is fixed now.
>
> julia

Thank You !
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] transform needing a calculation from a Python script

[Robert Larice]

Hello,
  attached is a very rough piece of .cocci which might
be an aproximation of your wish and julias hint.
  I assembled it as a sort of excersice for myself.
Regards,
  Robert

// For example, I’d like to transform:
// 
// #define BITMASK_A FOO(0x3F, 4) /* 0x3F0 */
// 
#define BITMASK_A FOO(0x3F, 4)  /* 0x3F0 --> 9,4 */
#define BITMASK_NOTSO FOO(0, 4) /* 0x000 */
#define BITMASK_B FOO(7, 8) /* 0x700 --> 10,8 */

void bar() {
FOO(0x3f, 4);   /* not converted */
}
// (compile "spatch --sp-file ex9.cocci ex9.c")

@initialize:python@
@@

def hweight(n):
return bin(n).count("1")

def contiguos_ones(n):
#   print n
#   print (n > 0) and ((n & (n+1)) == 0)
return (n > 0) and ((n & (n+1)) == 0)


@a@
constant x : script:python() { contiguos_ones(int(x, 0)) };
constant y;
identifier nam;
@@

#define nam FOO(x,y)

@script:python b@
x << a.x;
y << a.y;
xx;
yy;
@@

my_x = int(x, 0)
my_y = int(y, 0)
# print x
# print y
# print my_x
# print hweight(my_x)
coccinelle.xx = str(hweight(my_x) + my_y - 1)
coccinelle.yy = str(my_y)

@c@
constant a.x;
constant a.y;
identifier a.nam;
identifier b.xx;
identifier b.yy;
@@

- #define nam FOO(x,y)
+ #define nam GENMASK(xx,yy)
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] might be bug report, breaking up of a comment

[Robert Larice]

Julia Lawall <julia.law...@lip6.fr> writes:

> On Sat, 17 Feb 2018, Robert Larice wrote:
>
>> Hello,
>>
>>   attached is a small example which seems to
>> break up a comment line,
>> thus commenting out following lines.
>>
>>   Please look at the "long reuse" line
>> which will have an open comment when spatch is run,
>> thus commenting out the following "struct line *options"
>
> I also see this undesriable behavior.  Thanks for the report.
>
> julia

grepping a bit in the source code I found this:
  cpp_eat_until_nl
perhaps in the vicinity of the issue.

and there is this comment somewhere:

(* cpp recognize C comments, so when #define xx (yy) /* comment \n ... */
 * then he has already erased the /* comment. So:
 * - dont eat the start of the comment otherwise afterwards we are in the middle
 *   of a comment and so will problably get a parse error somewhere.
 * - have to recognize comments in cpp_eat_until_nl.
 *)

___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

[Cocci] might be bug report, breaking up of a comment

[Robert Larice]

Hello,

  attached is a small example which seems to
break up a comment line,
thus commenting out following lines.

  Please look at the "long reuse" line
which will have an open comment when spatch is run,
thus commenting out the following "struct line *options"

Best Regards,
  Robert Larice

// (compile "spatch --sp-file ex5.cocci ex5.c")

// a might be bug report

// in ex5.c there is a comment spawning to lines
// this patch seems to open up this comment (behind "long reuse"),
//   dropping its second half,
//   thus effectively commenting out following lines

@r2@
@@
- struct line
+ struct card
void
foobarbazi(
struct line *deck, /*in: the spice deck */
long reuse,/*in: TRUE if called from runcoms2.c com_rset,
 FALSE if called from inp_spsource() */
struct line *options   /*in: all .option lines from deck */
)
{
return 42;
}
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] please help me with a failing match

[Robert Larice]

Julia Lawall <julia.law...@lip6.fr> writes:

> On Sat, 17 Feb 2018, Robert Larice wrote:
>
>> Julia Lawall <julia.law...@lip6.fr> writes:
>>
>> > On Sat, 10 Feb 2018, Robert Larice wrote:
>> >
>> >> Julia Lawall <julia.law...@lip6.fr> writes:
>> >>
>> >> > On Sat, 10 Feb 2018, Robert Larice wrote:
>> >> >
>> >> >> Dear People,
>> >> >>
>> >> >>   I'm completely new here.
>> >> >>
>> >> >>   Attached is a small piece of .c and a .cocci file.
>> >> >>   There is a "return 41;" in both files, commented out.
>> >> >>   If I uncomment this "return 41;" in both files then
>> >> >> spatch will not match the pieces any more.
>> >> >>
>> >> >>   Could you please help me to undertand and circumvent this issue ?
>> >> >
>> >> > I have not noticed this problem before, but I suspect that it is due to
>> >> > the fact that Coccinelle is matching the control-flow path and not the
>> >> > abstract syntax tree. In a control-flow graph, nothing follows a return.
>> >> >
>> >> > julia
>> >>
>> >> Thank You,
>> >> I tried to sneak around the problem with a second "rule" which
>> >>   translates "return 42" to "auxiliary(42)".
>> >> My intention was to first change the source in such a way
>> >>   that the "control-flow" graph does not end at the "return",
>> >> and then hope that the second (accordingly modified) rule would
>> >>   match.
>> >> This didn't work, I assume I would have to express the idea of
>> >>   first applying the first rule
>> >> then to rebuild the control-flow graph
>> >>   then try the second rule.
>> >>   (and finally undo the changes of the first rule in a third rule)
>> >> I can not force "rebuild" without invoking spatch myself a second time.
>> >
>> > If you change all the returns to something else and then match your
>> > pattern, and then change them it should work.
>> >
>> >>
>> >> ---
>> >> I'm a bit of a maintainer for the "ngspice" project, which has a vast
>> >>   amount of very old files, and lots of semi duplicated stuff often crying
>> >>   for a thourough hair wash,
>> >> stumbled over this intresting tool, and am tying it for a certain
>> >>   rewrite I'm currently busy with.
>> >
>> > OK,feel free to ask more questions if you run into further issues.
>> >
>> > julia
>>
>> Hello,
>>
>>   Thank you for your help. I've four or five .cocci files now which
>> do the job at hand for ngspice quite well. The rewrite of return
>> to something else with two times invocation of spatch did work.
>>   Then I found another simpler way. So thats done.
>>
>>   Playing around, trying to better understand what it means
>> to have more than one rule, their interaction etc ..
>> I came to the attached example.
>>   Here I have basically tried to remove the whole body of a function
>> iff the function matches two other @rules@
>>   It seems to work if I use the '*' notation, but doesnt if I use
>> '+/-'
>>   Can you give me a hint which helps me to understand this ?
>
> For -+, Coccinelle requires that all control-flow paths from the starting
> point of the match match the complete rule. So for example a() ... b()
> would match the following:
>
> a();
> if (x)
>   b();
> else b();
>
> For *, it only requires the existence of such a path.
>
> If you have a -+ somewhere in the semantic patch, then all rules use the
> forall semantics.  If you have a * somewhere in the semantic patch, then
> all rules use the exists semantics.
>
> In your rule r2, you have ... Label: but this label is not reached on the
> execution path that ends in return 1.  When you have -+ somewhere in the
> semantic patch this rule is not satisfied.
>
> If you want to change the default for a rule, you can add exists for
> forall to the rule header, or put when exists or when forall on the ...
>
> julia

Thank You very much,

The behaviour, and what I have to do to fix it, is perfectly clear now,

Regards,
Robert
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] please help me with a failing match

[Robert Larice]

Julia Lawall <julia.law...@lip6.fr> writes:

> On Sat, 10 Feb 2018, Robert Larice wrote:
>
>> Julia Lawall <julia.law...@lip6.fr> writes:
>>
>> > On Sat, 10 Feb 2018, Robert Larice wrote:
>> >
>> >> Dear People,
>> >>
>> >>   I'm completely new here.
>> >>
>> >>   Attached is a small piece of .c and a .cocci file.
>> >>   There is a "return 41;" in both files, commented out.
>> >>   If I uncomment this "return 41;" in both files then
>> >> spatch will not match the pieces any more.
>> >>
>> >>   Could you please help me to undertand and circumvent this issue ?
>> >
>> > I have not noticed this problem before, but I suspect that it is due to
>> > the fact that Coccinelle is matching the control-flow path and not the
>> > abstract syntax tree. In a control-flow graph, nothing follows a return.
>> >
>> > julia
>>
>> Thank You,
>> I tried to sneak around the problem with a second "rule" which
>>   translates "return 42" to "auxiliary(42)".
>> My intention was to first change the source in such a way
>>   that the "control-flow" graph does not end at the "return",
>> and then hope that the second (accordingly modified) rule would
>>   match.
>> This didn't work, I assume I would have to express the idea of
>>   first applying the first rule
>> then to rebuild the control-flow graph
>>   then try the second rule.
>>   (and finally undo the changes of the first rule in a third rule)
>> I can not force "rebuild" without invoking spatch myself a second time.
>
> If you change all the returns to something else and then match your
> pattern, and then change them it should work.
>
>>
>> ---
>> I'm a bit of a maintainer for the "ngspice" project, which has a vast
>>   amount of very old files, and lots of semi duplicated stuff often crying
>>   for a thourough hair wash,
>> stumbled over this intresting tool, and am tying it for a certain
>>   rewrite I'm currently busy with.
>
> OK,feel free to ask more questions if you run into further issues.
>
> julia

Hello,

  Thank you for your help. I've four or five .cocci files now which
do the job at hand for ngspice quite well. The rewrite of return
to something else with two times invocation of spatch did work.
  Then I found another simpler way. So thats done.

  Playing around, trying to better understand what it means
to have more than one rule, their interaction etc ..
I came to the attached example.
  Here I have basically tried to remove the whole body of a function
iff the function matches two other @rules@
  It seems to work if I use the '*' notation, but doesnt if I use
'+/-'
  Can you give me a hint which helps me to understand this ?

Regards,
  Robert

// (compile "spatch --sp-file ex4.cocci ex4.c")

@r1@
identifier a, foo, Label;
position p1a;
@@
void foo@p1a (int a)
{
  a++;
  if (a)
  goto Label;
  return 1;
  ...
}

@r2@
identifier a, foo, Label;
position p1b;
@@
void foo@p1b (int a)
{
...
 Label:
return 2;
}

@r3@
identifier foo;
position r1.p1a;
position r2.p1b;
@@
void foo@p1a@p1b (...)
{
// this works thy way I'd expect
// * ...
// this doesn't work the way I'd expect
- ...
+ return 42;
}
void foo(int a) {
a++;
if (a)
goto Label;
return 1;
 Label:
return 2;
}


void foo2(int a) {
a++;
 Label:
return 2;
}
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] please help me with a failing match

[Robert Larice]

Julia Lawall <julia.law...@lip6.fr> writes:

> On Sat, 10 Feb 2018, Robert Larice wrote:
>
>> Dear People,
>>
>>   I'm completely new here.
>>
>>   Attached is a small piece of .c and a .cocci file.
>>   There is a "return 41;" in both files, commented out.
>>   If I uncomment this "return 41;" in both files then
>> spatch will not match the pieces any more.
>>
>>   Could you please help me to undertand and circumvent this issue ?
>
> I have not noticed this problem before, but I suspect that it is due to
> the fact that Coccinelle is matching the control-flow path and not the
> abstract syntax tree. In a control-flow graph, nothing follows a return.
>
> julia

Thank You,
I tried to sneak around the problem with a second "rule" which
  translates "return 42" to "auxiliary(42)".
My intention was to first change the source in such a way
  that the "control-flow" graph does not end at the "return",
and then hope that the second (accordingly modified) rule would
  match.
This didn't work, I assume I would have to express the idea of
  first applying the first rule
then to rebuild the control-flow graph
  then try the second rule.
  (and finally undo the changes of the first rule in a third rule)
I can not force "rebuild" without invoking spatch myself a second time.

---
I'm a bit of a maintainer for the "ngspice" project, which has a vast
  amount of very old files, and lots of semi duplicated stuff often crying
  for a thourough hair wash,
stumbled over this intresting tool, and am tying it for a certain
  rewrite I'm currently busy with.
  

___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

[Cocci] please help me with a failing match

[Robert Larice]

Dear People,

  I'm completely new here.

  Attached is a small piece of .c and a .cocci file.
  There is a "return 41;" in both files, commented out.
  If I uncomment this "return 41;" in both files then
spatch will not match the pieces any more.

  Could you please help me to undertand and circumvent this issue ?

Best Regards,
  Robert Larice

// (compile "spatch --sp-file try-goto-2.cocci try-goto-2.c")

@trygoto@
identifier fn, Xp1, Xlabel;
@@
  int fn (int Xp1)
  {
if (Xp1 > 42) {
*   goto Xlabel;
}

// the match fails if I uncomment this return statement
// in both the .c file and the .cocci file
//return 41;

Xlabel:
return 43;
  }
int
foo(int n)
{
if (n > 42)
goto Lbaz;

//   return 41;

 Lbaz:
return 43;
}
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci