On Mon, 13 Apr 2020, Markus Elfring wrote:
> >>> Maybe you consider the following results to be a problem:
> >>>
> >>> kzalloc mcde [("mcde_probe", 2, 0, 198, 1, "m.c", 16, 1, 16, 3)]
> >>> kzalloc ! mcde [("mcde_probe", 2, 0, 198, 1, "m.c", 16, 1, 16, 3)]
> >>> platform_get_irq irq [("mcde_probe", 2, 0, 198, 1, "m.c", 97, 1, 97, 3)]
> >>> platform_get_irq ! irq [("mcde_probe", 2, 0, 198, 1, "m.c", 97, 1, 97, 3)]
> >>>
> >>> The positions are the same. The result is because of an isomorphism that
> >>> exchanges the branches of a conditional.
>
> I would find it nice to explain the different software behaviour for the
> mentioned
> SmPL code variants
Run spatch -parse-cocci and you will easily see. The if stays in the same
place. When the isomorphism exchanges the branches, the condition gets
negated, so in one case you get the position of the full condition and in
the other case you get the position of the part of the condition under the
negation.
julia
>
> A:
> if@p (
> ( <+... result ...+>
> & check
> ) )
>
>
> B:
> if (
> ( <+... result ...+>
> & check@p
> ) )
>
>
>
> >> Can the data which are provided because of isomorphism transformations
> >> be distinguished by an additional attribute?
> >
> > I think that you just want to disable the isomorphism. Put disable neg_if
> > in the initial @@ of your rule.
>
> Thanks for this suggestion.
>
> Source code analysis can be continued also with this configuration option.
>
>
> Now I become also more interested in improvements around parallel data
> processing.
> Which data structures would support aggregate computations for a growing code
> base?
>
> Regards,
> Markus
>
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci
