>>> 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
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
