The example could be simplified to:
@is_assigned@
position p;
expression a, b, x, y;
identifier c, d;
type t;
@@
(
y@p = (t) (x)(...)
|
y@p = (t) (a)->c(...)
|
y@p = (t) (b).d(...)
)
...
@is_assigned_without_when_filters@
position p != is_assigned.p;
expression x, y;
type t;
@@
*y@p = (t) (x)(...)
-----------------
int main(void)
{
y = mop->add(1, 2);
y = mo.add(3, 4);
}
-----------------
The question is not really why is y = mo.add(3, 4); not marked, but more
why is anything marked at all.
The reason is that ... matches the shortest path between what is before
the ... and what is after (implicitly the end of the function in this
case). For the code y = mop->add(1, 2);, the disjunction at the beginning
of is_assigned matches, so it checks to see that this disjunction is not
satisfied by any code between this point and the end of the function.
This is not the case, though, because the branch of the disjunction y@p =
(t) (b).d(...) matches the code y = mo.add(3, 4);. So the position of the
first call is not recorded in is_assigned.
On the other hand, for the second assignment, there is thing that matches
the disjunction between that assignment and the end of the function.
Thus, the position variable is bound in this case.
The second rule then marks cases where the position variable is not bound.
This is only y = mop->add(1, 2);
If you are trying to find cases where variables are assigned but are not
used, then you are not at all doing that. Indeed you are doing the
opposite.
The semantic patch is also unnecessarily verbose. Actually (a)->c is an
expression, so any code that it matches would also be matched by (x).
Furthermore, you can reuse metavariables between disjunction branches, eg
c and d can be the same metavariable in is_assigned. And you can also
reuse metavariables between a sequence of whens.
julia
_______________________________________________
Cocci mailing list
[email protected]
http://lists.diku.dk/mailman/listinfo/cocci
(Web access from inside DIKUs LAN only)
