On Fri, 23 Sep 2022, Markus Elfring wrote:
> >> # How do you think about the handling of multiple members within data structures?
> > There should be no problem with this.
>
>
> Would it be relevant to use the SmPL construct “<+... … ...+>”?
Not in a structure definition.
>
>
>
> >> # How much does it matter here that curly brackets are used for a proposed SmPL constraint?
> > I have no idea what "How much does it matter" mean. {} are used because
> > that's how struct types are declared.
>
>
> Please take another look at mentioned implementation details for
> the clarification of such communication difficulties.
>
> A)
> position p != {r2.p};
>
> B)
> position p != find_member.p;
OK, both are fine. If there are multiple positions that p should be
different from then the {} would be required.
>
>
> >> I got another development concern for the presented algorithm.
> >> Why is a data initialisation function call searched in the first SmPL rule at all?
> > Because he wants to find the fields for which mutex_init is already called
> > and to not report messages for them. That is the whole point of the
> > semantic patch.
>
>
> How do you think about an opposite source code search order?
>
> Would you like to search for function calls which require initialised
> data structures before any additional source code analysis?
It doesn't make much sense to have a mutex without initializing it.
julia
