Re: [Cocci] Removing the last return statement from a void function
On Fri, 19 Mar 2021, Thomas Adam wrote:
> On Thu, 18 Mar 2021 at 19:24, Julia Lawall wrote:
>
> > The ... in Coccinelle is based on control flow, so it is a bit hard to
> > find the return at the bottom of the function. Actually, from
> > Coccinelle's point of view, all returns are at the bottom of the function,
> > because one leaves the function after a return.
>
> Interesting, that helps me understand a little more about Coccinelle. Thanks.
>
> > You can try the following:
> >
> > @r@
> > position p;
> > identifier f;
> > }
> >
> > f(...) {
> > <...
> > { .. return@p; }
> > ...>
> > }
> >
> > @@
> > position p != r.p;
> > @@
> >
> > - return@p;
>
> So I tried this:
>
> @r@
> position p;
> identifier f;
> @@
>
> f(...) {
> <...
>{ ... return@p; }
> ...>
> }
>
> @@
> position p != r.p;
> @@
>
> - return@p;
>
> Which I ran as:
>
> spatch --in-place --debug --iso-file contrib/coccinelle/empty.iso \
> --sp-file ./contrib/coccinelle/remove-void-return.cocci --dir fvwm
>
> With "--dir fvwm", I found that my CPU was being chewed at 100%, which I left
> running overnight. Some 8 hours later, spatch was still running. Presumably,
> Coccinelle is having an interesting time coordinating the positions?
>
> Instead, I decided to loop over the .c files which "--dir fvwm" would have
> done. What I found was that for some files, spatch took a few seconds, and
> produced no output, yet for some, spatch was still running without any result
> known (so I killed it).
>
> Indeed, I'm attaching a debug run of spatch to this email (cocci-debug) for
> one file that definitely has functions where I would expect Coccinelle to have
> matched a "return;" statement to be removed, but this wasn't the case.
>
> Would you be able to suggest what I might have done wrong, or if there's any
> additional debugging I can provide?
If Coccinelle gets stuck on one part of a file, it won't move on to the
next part. So the fact that the something should have been done in the
file is not really helpful.
You can use the argument --show-trying to see what function it is working
on at the moment.
You can use --timeout N to limit the treatment of a given file to N
seconds.
It may help to replace @r@ by @r exists@.
julia
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] Removing the last return statement from a void function
On Thu, 18 Mar 2021 at 19:24, Julia Lawall wrote:
> The ... in Coccinelle is based on control flow, so it is a bit hard to
> find the return at the bottom of the function. Actually, from
> Coccinelle's point of view, all returns are at the bottom of the function,
> because one leaves the function after a return.
Interesting, that helps me understand a little more about Coccinelle. Thanks.
> You can try the following:
>
> @r@
> position p;
> identifier f;
> }
>
> f(...) {
> <...
> { .. return@p; }
> ...>
> }
>
> @@
> position p != r.p;
> @@
>
> - return@p;
So I tried this:
@r@
position p;
identifier f;
@@
f(...) {
<...
{ ... return@p; }
...>
}
@@
position p != r.p;
@@
- return@p;
Which I ran as:
spatch --in-place --debug --iso-file contrib/coccinelle/empty.iso \
--sp-file ./contrib/coccinelle/remove-void-return.cocci --dir fvwm
With "--dir fvwm", I found that my CPU was being chewed at 100%, which I left
running overnight. Some 8 hours later, spatch was still running. Presumably,
Coccinelle is having an interesting time coordinating the positions?
Instead, I decided to loop over the .c files which "--dir fvwm" would have
done. What I found was that for some files, spatch took a few seconds, and
produced no output, yet for some, spatch was still running without any result
known (so I killed it).
Indeed, I'm attaching a debug run of spatch to this email (cocci-debug) for
one file that definitely has functions where I would expect Coccinelle to have
matched a "return;" statement to be removed, but this wasn't the case.
Would you be able to suggest what I might have done wrong, or if there's any
additional debugging I can provide?
Thanks,
Thomas
cocci-debug
Description: Binary data
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] [PATCH] scripts/coccinelle: Add script to detect sign extension
On Fri, 19 Mar 2021, Evan Benn wrote:
> Hello,
>
> I am attempting to create a coccinelle script that will detect possibly buggy
> usage of the bitwise operators where integer promotion may result in bugs,
> usually due to sign extension.
>
> I know this script needs a lot more work, but I am just beginning to learn the
> syntax of coccinelle. At this stage I am mainly looking for advice if this is
> even worth continuing, or if I am on the wrong track entirely.
I'm not really an expert in the problem, so I don't know exactly what are
the kinds of code you want to find. Coccinelle is good at matching the
types of things and the structure of things. If you need to know the
actual values of things, you may want to try smatch. Coccinelle probably
doesn't have complete knowledge of how various operators affect C types.
For example, it would not have known that BIT results in a long.
The best you can do is try some rules and see what the results are, and
try to collect some relevant examples and see if you can match them with
your rules. Please write back if there is some specific code that is not
matched as expected.
julia
>
> Here is an example of the bug I hope to find:
>
> https://lore.kernel.org/lkml/20210317013758.ga134...@roeck-us.net/
>
> Where ints and unsigned are mixed in bitwise operations, and the sizes differ.
>
> Thanks
>
> Evan Benn
>
> Signed-off-by: Evan Benn
> ---
>
> .../coccinelle/tests/int_sign_extend.cocci| 35 +++
> 1 file changed, 35 insertions(+)
> create mode 100644 scripts/coccinelle/tests/int_sign_extend.cocci
>
> diff --git a/scripts/coccinelle/tests/int_sign_extend.cocci
> b/scripts/coccinelle/tests/int_sign_extend.cocci
> new file mode 100644
> index ..bad61e37e4e7
> --- /dev/null
> +++ b/scripts/coccinelle/tests/int_sign_extend.cocci
> @@ -0,0 +1,35 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/// Mixing signed and unsigned types in bitwise operations risks problems
> when
> +/// the 'Usual arithmetic conversions' are applied.
> +/// For example:
> +/// https://lore.kernel.org/lkml/20210317013758.ga134...@roeck-us.net/
> +/// When a signed int and an unsigned int are compared there is no problem.
> +/// But if the unsigned is changed to a unsigned long, for example by using
> BIT
> +/// the signed value will be sign-extended and could result in incorrect
> logic.
> +// Confidence:
> +// Copyright: (C) 2021 Evan Benn
> +// Comments:
> +// Options:
> +
> +virtual context
> +virtual org
> +virtual report
> +
> +@r@
> +position p;
> +{int} s;
> +{unsigned long} u;
> +@@
> +s@p & u
> +
> +@script:python depends on org@
> +p << r.p;
> +@@
> +
> +cocci.print_main("sign extension when comparing bits of signed and unsigned
> values", p)
> +
> +@script:python depends on report@
> +p << r.p;
> +@@
> +
> +coccilib.report.print_report(p[0],"sign extension when comparing bits of
> signed and unsigned values")
> --
> 2.31.0.291.g576ba9dcdaf-goog
>
>
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci
