On Tue, 10 May 2022, Alessandro Carminati wrote:

> Hello Markus,
>
>
> Il giorno lun 9 mag 2022 alle ore 21:23 Markus Elfring
> <Markus.Elfring@web.de> ha scritto:
>
>             The solution you sent indeed does what I expected.
>
>
> I doubt that it fits to your initial source code analysis desire.
>
> Are your expectations still evolving (also for your data processing
> needs)?
>
> Indeed Julia's proposed code does not solve all the situations I encounter
> now  in the kernel source analysis.
> It reports not only global variable names but also function names.
> It confuses sparse annotation and a few other macros with variable names.
> I also have trouble with "extern" declared variables that appear multiple
> times.
> Still, it is far better than I was up to, And it allows me to improve the
> solution by adding statements and rules to make it better suit my use case.
> Currently, I'm using this, but I still have duplicates due to "extern"
> declarations.
> ```
> @func@
> type T;
> identifier i;
> position p : script:python(i) { p[0].current_element == i};
> @@
>
> T i(...)@p;
>
>
> @r depends on !func@
> type T;
> identifier i;
> expression E;
> position p : script:python(i) { p[0].current_element == i};
> @@

Thanks for the feedback.  The strategy of !func is a good idea, but it is
not correct.  There is no particular relation between the func rule and
this one.  Thus as soon as a file contains code that matches the func
rule, the file will be ignored.

One solution would be to check that the position of i is not the same as
the position of a name matched by the func rule.  For that, you could move
the @p in the func rule from the ) to the function name, and then in this
rule put as the first metavariable line:

position q != func.p;

and then in the matches below put i@q@p (ensure that is at a position
that is both different than any func.p and that it satisfies the
current_element constraint).

But in this case, there is a solution that is even simpler:

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

Indeed, I think it should be sufficient to say:

(
T i(...);
|
T i@p=...;
)

You can run spatch --parse-cocci to see what happens with the rewriting
due to isomorphisms to see if the simpler rule is sufficient.

Or maybe you want:

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


>
> (
>  T i@p;
> |
>  T i@p=E;
> )
>
> @script:python@
> i << r.i;
> @@
> print (i)

Maybe you also want to inherit the position variable and print the file
and line number of the declaration?

julia

> ```
>
>
>
>             Would you mind add a short explanation of this
>             statement:
>             `position p : script:python(i) {
>             p[0].current_element == i};`
>             I probably have a simplified understanding of what a
>             position is.
>
> I imagine that known information sources can help further.
>
> https://gitlab.inria.fr/coccinelle/coccinelle/-/blob/5069eaeadd731ecdd99e7a
> 6f4465c286a2792354/docs/manual/cocci_syntax.tex#L410
> https://github.com/coccinelle/coccinelle/blob/ae337fce1512ff15aabc3ad5b6d2e
> 537f97ab62a/docs/manual/cocci_syntax.tex#L410
>
> Thanks for this.  
>
>
>
>
>             Maybe it is worth digging deeper and having a more
>             concrete knowledge.
>
>
> Probably, yes.
>
>
>
>       Any read you want to suggest to me?
>
>
> Related links for example:
>
> https://gitlab.inria.fr/coccinelle/coccinelle/-/blob/5069eaeadd731ecdd99e7a
> 6f4465c286a2792354/docs/Coccilib.3cocci#L5
> https://github.com/coccinelle/coccinelle/blob/57cbff0c5768e22bb2d8c20e8dae7
> 4294515c6b3/docs/Coccilib.3cocci#L5
>
>
>
> Regards,
> Markus
>
>
>