Re: [cocci] Searching for lock calls without unlocking (with SmPL)?

[Julia Lawall <julia.lawall@inria.fr>]

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



On Sat, 2 Aug 2025, Markus Elfring wrote:

> >>> Would you get into the mood to clarify data processing challenges better
> >>> for another source code search pattern (like the following)?
> >>
> >> How reasonable would you find a test result for another source code search approach?
> >
> > Completely reasonable.
>
> I got an other understanding for the functionality of the Coccinelle software here
> so far.
>
>
> >                         You match pairs of subsequent locks, but you only
> > mark the second one in the pair.  So you match two pairs:
> >
> > action_lock(&blockage1); and action_lock(&blockage2);
> >
> > and
> >
> > action_lock(&blockage2); and action_lock(&blockage2);
> >
> > and you mark the second one in each case.
>
> It seems that our data processing expectations differ once more.
>
>
> > It would greatly help communication if you would also provide the answer
> > that you expect.
>
> A “shortest path constraint” is mentioned for the usage of the SmPL ellipsis.
> https://gitlab.inria.fr/coccinelle/coccinelle/-/blob/3aa9a6ab3b035e31292be31399b99a8857480aef/docs/manual/cocci_syntax.tex#L1035-1043
>
>
> …>> @display@
> >> expression x, y;
> >> @@
> >>  action_lock(x);
> >>  ... when != action_unlock(x);
> >> *action_lock(y);
>
> May I expect that only a single call should be marked for such a test case?

No, I already explained why two calls are marked.

The shortest path constraint is that for A ... B, the ... doesn't contain
A or B.  It doesn't mean that the rule can't match at multiple places in
the function.

julia