[Cocci] Weird problem trying to match code inside a function

[Luca Coelho]

Hi Julia,

I bumped in to another weird problem. I'm trying to match some code
inside a function that has a specific struct as a parameter, but I
can't get it to work.

This is cocci code I tried first:

http://pastebin.coelho.fi/6f8f346822a7c99e.txt

And this is the file I'm trying to match:

http://pastebin.coelho.fi/f73f542932add1c6.txt

The led activate op changed from being a function that returns void to
one that returns int and I had to backport that.

The strange thing is that if I have only the first rule, it works fine,
but when I add the second rule it fails.

I can make it work if I match the entire code, without trying to match
the function in the first rule:

http://pastebin.coelho.fi/46c18ce890330d57.txt

And this is fine for me now, but I'm really curious as to why I had the
problem with my first implementation...

Can you shed some light?

--
Cheers,
Luca.

[Julia Lawall]

Post by Luca Coelho
Hi Julia,
I bumped in to another weird problem. I'm trying to match some code
inside a function that has a specific struct as a parameter, but I
can't get it to work.
http://pastebin.coelho.fi/6f8f346822a7c99e.txt
http://pastebin.coelho.fi/f73f542932add1c6.txt
The led activate op changed from being a function that returns void to
one that returns int and I had to backport that.
The strange thing is that if I have only the first rule, it works fine,
but when I add the second rule it fails.

I didn't look at the code in detail, but there is a restriction on
metavariables that are not position variables that are inherited from one
rule to another. Such metavariables have to have only one value. If
there is more than one possible value, the original match fails
completely.

For example, if you do:

@r@
expression E;
@@

f();
...
-g(E);

This will do the right thing for:

f();
if (x)
g(3);
else g(4);

But if you do:

@r@
expression E;
@@

f();
...
-g(E);

@@
expression r.E;
@@

- xxx(E);

Then nothing will happen at all. Because in the first rule, it is not
able to find a unique binding for E.

A solution can be:

@r@
expression E;
position p;
@@

f();
...
g(***@p);

@s@
position r.p;
expression E;
@@

- g(***@p);

@@
expression s.E;
@@

- xxx(E);

Position metavariable can take on many values, even if they are inherited.

julia

Post by Luca Coelho
I can make it work if I match the entire code, without trying to match
http://pastebin.coelho.fi/46c18ce890330d57.txt
And this is fine for me now, but I'm really curious as to why I had the
problem with my first implementation...
Can you shed some light?
--
Cheers,
Luca.

[Luca Coelho]

Post by Julia Lawall

Post by Luca Coelho
Hi Julia,
I bumped in to another weird problem. I'm trying to match some code
inside a function that has a specific struct as a parameter, but I
can't get it to work.
http://pastebin.coelho.fi/6f8f346822a7c99e.txt
http://pastebin.coelho.fi/f73f542932add1c6.txt
The led activate op changed from being a function that returns void to
one that returns int and I had to backport that.
The strange thing is that if I have only the first rule, it works fine,
but when I add the second rule it fails.

I didn't look at the code in detail, but there is a restriction on
metavariables that are not position variables that are inherited from one
rule to another. Such metavariables have to have only one value. If
there is more than one possible value, the original match fails
completely.
@r@
expression E;
@@
f();
...
-g(E);
f();
if (x)
g(3);
else g(4);
@r@
expression E;
@@
f();
...
-g(E);
@@
expression r.E;
@@
- xxx(E);
Then nothing will happen at all. Because in the first rule, it is not
able to find a unique binding for E.
@r@
expression E;
position p;
@@
f();
...
@s@
position r.p;
expression E;
@@
@@
expression s.E;
@@
- xxx(E);
Position metavariable can take on many values, even if they are inherited.

Ah, I think this explains the problem.

I tried to add the position thing in my rules, but I didn't succeed.
I'll have to try again at some other time. My rules without matching
inside a function work fine, so I'll leave with that for now.

Thanks!

--
Luca.

[SF Markus Elfring]

Post by Luca Coelho
Can you shed some light?

Did you notice the following information in the manual for the semantic
patch language?
https://github.com/coccinelle/coccinelle/blob/dd206b29bf372a8f8e63ffe549f8184e10f2ea7e/docs/manual/cocci_syntax.tex#L1607

“…
All matching done by a SmPL rule is done intraprocedurally.
…”


Can this trigger software development considerations when you try
to add source code after a found function implementation?

Regards,
Markus

[Julia Lawall]

Post by SF Markus Elfring

Post by Luca Coelho
Can you shed some light?

Did you notice the following information in the manual for the semantic
patch language?
https://github.com/coccinelle/coccinelle/blob/dd206b29bf372a8f8e63ffe549f8184e10f2ea7e/docs/manual/cocci_syntax.tex#L1607
“

All matching done by a SmPL rule is done intraprocedurally.

”
Can this trigger software development considerations when you try
to add source code after a found function implementation?

As the manual says, all matching is done within a function. Adding code
is not matching.

julia