Re: [cocci] List global variables with SmPL

[Alessandro Carminati <alessandro.carminati@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3032 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 4017 bytes --]