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.