From: Robert.Larice@t-online.de (Robert Larice)
To: cocci@systeme.lip6.fr
Subject: [Cocci] perhaps a bug
Date: Sun, 29 Apr 2018 20:12:17 +0200 [thread overview]
Message-ID: <kklgd5ubjy.fsf@bora.foobar.de> (raw)
In-Reply-To: <alpine.DEB.2.20.1804292001030.3679@hadrien> (Julia Lawall's message of "Sun, 29 Apr 2018 20:03:47 +0200 (CEST)")
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
prev parent reply other threads:[~2018-04-29 18:12 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-29 12:46 [Cocci] perhaps a bug Robert Larice
2018-04-29 12:58 ` Julia Lawall
2018-04-29 13:06 ` Robert Larice
2018-04-29 13:16 ` Julia Lawall
2018-04-29 13:43 ` Robert Larice
2018-04-29 14:00 ` Julia Lawall
2018-04-29 18:03 ` Julia Lawall
2018-04-29 18:12 ` Robert Larice [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=kklgd5ubjy.fsf@bora.foobar.de \
--to=robert.larice@t-online.de \
--cc=cocci@systeme.lip6.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.