Post by Robert LaricePost by Julia LawallPost by Robert LaricePost by Julia LawallPost by Robert LariceHello,
attached is a small example which does something strange
to a "int i, j;" within a "#ifdef..."
Perhaps this points to a bug in coccinelle,
Would you please check ?
Thanks for the report. It looks like a bug. But everything is fine if
you removed the --defined BOO.
julia
Yes, in this example it works without this --defined announcement.
I stumbled on this with something more complex, which for some
reason I don't understand yet ignores a wanted transformation
in a #ifdef..#endif, except if I add such a --defined.
Only then it honours my transformation, but fails with this bug.
I don't think the --defined option has been tested much. Perhaps without
the --defined there is a parse error on the function.
julia
Hello Julia,
I've attached a ripped down example to show the behaviour
with regard to the #ifdef
Without the --defined, nothing gets tranformed.
I don't see a parsing problem so far.
Perhaps you can have a look and get an idea why
here the --defined is important.
I've seen other transformations where this was not necessairy.
OK, thanks for the example. It is indeed not a parsing problem. When
#ifdefs are reasonably well behaved, Coccinelle internally considers them
to have a control-flow structure like an if - the code in the #ifdef might
be there or it might not. On the other hand your rule requires that there
is exactly one i = 0 on each control-flow path through the loop. If you
just want to remove any that happen to exist, you can instead write:
<...
- i = 0;
...>
This will also remove cases where there are multiple initializations of i
to 0 within the loop.
julia