>>> If you want to be sure that you aren't in a loop,
>>
>> I do not want to filter on this implementation detail for the shown analysis
>> approach.
>
> I don't know what you mean by "I do not want to".
I suggest to improve this clarification by additional case distinctions.
> You mean that
> If you want to be sure that you aren't in a loop,
I do not want to filter on this implementation detail for the shown analysis
approach.
> you have to ue position variables to be sure that the two matched fragments
> are different.
I find this information questionable.
* How should source
> If you want to be sure that you aren't in a loop,
I have got other expectations for the software behaviour.
> you have to ue position variables to be sure that the two matched fragments
> are different.
I wonder how loops could matter for the presented analysis approach.
Regards,
Markus
> Your ifs may be in a loop.
Such source code structures are actually shown for the first two diff hunks.
Will any further adjustments be needed to take this aspect better into account
for the presented analysis approach?
Regards,
Markus
___
Cocci
Hello,
I have constructed the following small SmPL script.
@duplicated_code@
identifier work;
statement s1, s2;
type T;
@@
T work(...)
{
... when any
*if (...)
*{
... when any
* s1
* s2
*}
... when any
*if (...)
*{
... when any
* s1
* s2
*}
... when any
}
Test result:
