[Cocci] perhaps a bug

[Cocci] perhaps a bug

[Robert Larice]

Hello,

  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 ?

Best Regards,
  Robert

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ex1.c
Type: text/x-csrc
Size: 122 bytes
Desc: not available
URL: <https://systeme.lip6.fr/pipermail/cocci/attachments/20180429/e536b96f/attachment.bin>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ex1.cocci
URL: <https://systeme.lip6.fr/pipermail/cocci/attachments/20180429/e536b96f/attachment.ksh>

[Cocci] perhaps a bug

[Julia Lawall]

On Sun, 29 Apr 2018, Robert Larice wrote:

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

[Cocci] perhaps a bug

[Robert Larice]

Julia Lawall <julia.lawall@lip6.fr> writes:

> On Sun, 29 Apr 2018, Robert Larice wrote:
>
>> Hello,
>>
>>   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 certainly will try to work around somehow.

Regards,
  Robert

[Cocci] perhaps a bug

[Julia Lawall]

On Sun, 29 Apr 2018, Robert Larice wrote:

> Julia Lawall <julia.lawall@lip6.fr> writes:
>
> > On Sun, 29 Apr 2018, Robert Larice wrote:
> >
> >> Hello,
> >>
> >>   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

[Cocci] perhaps a bug

[Robert Larice]

Julia Lawall <julia.lawall@lip6.fr> writes:

> On Sun, 29 Apr 2018, Robert Larice wrote:
>
>> Julia Lawall <julia.lawall@lip6.fr> writes:
>>
>> > On Sun, 29 Apr 2018, Robert Larice wrote:
>> >
>> >> Hello,
>> >>
>> >>   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.

Best Regards,
  Robert

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ex3.c
Type: text/x-csrc
Size: 372 bytes
Desc: not available
URL: <https://systeme.lip6.fr/pipermail/cocci/attachments/20180429/ac526743/attachment-0001.bin>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ex3.cocci
URL: <https://systeme.lip6.fr/pipermail/cocci/attachments/20180429/ac526743/attachment-0001.ksh>

[Cocci] perhaps a bug

[Julia Lawall]

On Sun, 29 Apr 2018, Robert Larice wrote:

> Julia Lawall <julia.lawall@lip6.fr> writes:
>
> > On Sun, 29 Apr 2018, Robert Larice wrote:
> >
> >> Julia Lawall <julia.lawall@lip6.fr> writes:
> >>
> >> > On Sun, 29 Apr 2018, Robert Larice wrote:
> >> >
> >> >> Hello,
> >> >>
> >> >>   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.

Thanks.  Coccinelle doesn't show parsing problems by default.  You can see
them with spatch --parse-c foo.c or with the --verbose-parsing option.

julia

>
> Best Regards,
>   Robert
>
>

[Cocci] perhaps a bug

[Julia Lawall]

On Sun, 29 Apr 2018, Robert Larice wrote:

> Julia Lawall <julia.lawall@lip6.fr> writes:
>
> > On Sun, 29 Apr 2018, Robert Larice wrote:
> >
> >> Julia Lawall <julia.lawall@lip6.fr> writes:
> >>
> >> > On Sun, 29 Apr 2018, Robert Larice wrote:
> >> >
> >> >> Hello,
> >> >>
> >> >>   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

[Cocci] perhaps a bug

[Robert Larice]

Julia Lawall <julia.lawall@lip6.fr> writes:

> On Sun, 29 Apr 2018, Robert Larice wrote:
>
>> Julia Lawall <julia.lawall@lip6.fr> writes:
>>
>> > On Sun, 29 Apr 2018, Robert Larice wrote:
>> >
>> >> Julia Lawall <julia.lawall@lip6.fr> writes:
>> >>
>> >> > On Sun, 29 Apr 2018, Robert Larice wrote:
>> >> >
>> >> >> Hello,
>> >> >>
>> >> >>   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

Thank You for your helpfull description,

  in face of this I can well understand the why,
  and how to work around.

Best Regards,
  Robert