I'm planning to stop bugging this mailing list, but before that, please allow me a final question. That is related to what I have done so far.
My current implementation is the following.
```
@excluded@
type T;
identifier i;
position p;
@@

(
 T i@p(...);
|
 extern T i@p;
|
 T i@p(...,......);
)


@r@
type T;
identifier i;
expression E;
position q != excluded.p;
position p : script:python(i) { p[0].current_element == i};
attribute name __randomize_layout;
@@

(
 T i@q@p;
|
 T i@q@p=E;
)

@rr@
type T;
identifier i;
expression E;
attribute name __randomize_layout;
@@

(
 T i;
|
 T i=E;
)

@script:python@
i << excluded.i;
@@
print (i)
```
It is a suboptimal version of Julia's last proposition.
It happens that in a file a statement I expect to be matched is not detected.
Troubleshooting the issue, I see a behavior that does not fit the model I have in my mind. This suggests to me that things (coccinelle under the hood mechanisms) are more complicated than I think.
back to the point:
Running the script and printing only the rule "rr", which is the same as "r" without positions, the results presents a set of entries containing the entry I'm interested in.
Running the same script but printing only the rule "excluded", I see that the result is an empty set.
Finally, running the script using only the "r" rule, the entry I'm interested in is not there.

Surprisingly (for me), removing the position constraints coming from the rule "excluded" (position q != excluded.p;) from the rule "r", the entry appears.
My question then is the following: How can the rule "excluded" that presents an empty set influence the rule "r"?
Speculating Julia's words on a previous answer I got, I guessed that somehow an empty set could be treated differently, so I added a line into the target c file to make at least "excluded" match one line. But it didn't make any difference.

Alessandro 



Il giorno mar 10 mag 2022 alle ore 12:39 Julia Lawall <julia.lawall@inria.fr> ha scritto:
Here is a suggested solution for all of the problems reported so far:

@r@
type T;
identifier i;
expression E;
position p : script:python(i) { p[0].current_element == i };
attribute name __randomize_layout;
@@

(
T i(...);
|
T i(...,......);
|
extern T i;
|
T i@p;
|
T i@p=E;
)

@script:python@
i << r.i;
p << r.p;
@@
print (i)

----------------------

The problem with __randomize_layout is that the Coccinelle parser is not
recognizing it as an attribute.  You can force that by putting a
declaration in the semantic patch.

It seems that ... in a function parameter list does not match the ... in C
for a variable list of arguments.  That ... can be matched explicitly by
...... so I have added another case with that.

I als combined all of the patterns into one rule.  By inheriting the
position varaible p into the python rule at the end, that python rule is
only executed if p is defined, which makes it select the cases of interest
and ignore the others.

julia