On Wed, 11 May 2022, Alessandro Carminati wrote:

>
> Alessandro
>
>
>
> Il giorno mer 11 mag 2022 alle ore 10:14 Julia Lawall <julia.lawall@inria.fr> ha scritto:
>       > 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.
>
>       You haven't provided tihs semantic patch, so I don't know in detail what
>       it does.
>
> It appears I do not know what a semantic patch is.
> I was convinced that what I called the "script" included inline in the mail I sent was the semantic patch.

It is, but you said that you removed something.  Removing that thing is
not trivial because other things depend on it.  So I don't know exactly
what you did.

In your rr.cocci rule, an isomorphism applies to the pattern T i; to allow
it to match T i = ...; so the problem is solved.  This isomorphism does
not apply when there are position variables attached to the declared
identifier.  This information is provided when running spatch
--parse-cocci by the following message:

warning: iso decl_init does not match the code below on line 26
T i@p@q;

context metavariable Z is matched against the following
noncontext code:
i@p@q

You can see the definition of decl_init in the file standard.iso.

I'm not sure that this strategy for isomorphisms is correct.  At least in
this case, there seems to be no harm in considering i to be in a context
position.  It's not removed or added.  I'm not sure why having a position
metavariable disqualifies is.

julia

>
>
>       In my opinion, the rule excluded is completely irrelevant for this
>       example.  The code that you want to detect is:
>
>       const struct snd_soc_component_driver mtk_afe_pcm_platform = {
>               .name           = AFE_PCM_NAME,
>               .pointer        = mtk_afe_pcm_pointer,
>               .pcm_construct  = mtk_afe_pcm_new,
>       };
>
>       {
>               .name           = AFE_PCM_NAME,
>               .pointer        = mtk_afe_pcm_pointer,
>               .pcm_construct  = mtk_afe_pcm_new,
>       }
>
>       is not considered to be an ordinary expression, but rather as an
>       initializer.  Everything should work find if you just replace E by ...
>
>
> Indeed, replacing the E with ... solves the issue.
> The explanation makes sense to me,  but why does the rule rr in the following context matches mtk_afe_pcm_platform and presents the following resulting set?
> ```
> $ spatch  -sp_file  simple.cocci mtk-afe-platform-driver.c
> init_defs_builtins: /usr/local/lib/coccinelle/standard.h
> HANDLING: mtk-afe-platform-driver.c
> afe
> dai
> dai_idx
> dev
> hw_base
> hw_ptr
> memif
> memif_data
> mtk_afe_pcm_platform
> num_dai_drivers
> pcm
> pcm_ptr_bytes
> reg_ofs_base
> reg_ofs_cur
> regmap
> ret
> rtd
> size
> ```
> and simple.cocci is
> ```
> @rr@
> type T;
> identifier i;
> expression E;
> attribute name __randomize_layout;
> @@
>
> (
>  T i;
> |
>  T i=E;
> )
>
> @script:python@
> i << rr.i;
> @@
> print (i)
> ```
>
>
>       julia
>
>
>