Re: [Cocci] getting rid of implicit boolean expressions
On Wed, 21 Apr 2021, Akos Pasztory wrote:
> Hi,
>
> I'm trying do the following kind of transformations:
>
> int x, y;
> char *p;
> bool b, c;
>
> -b = x || !y;
> +b = (x != 0) || (y == 0);
>
> -c = !p;
> +c = (p == NULL);
>
> -if (x & 3)
> +if ((x & 3) != 0)
> f();
> // etc
>
> That is: trying to eliminate implicit boolean-ness (and add parentheses as
> well).
>
> I was thinking along the lines of first finding expressions
> that are in "boolean context" (part of a || or && expression,
> or an if/for/while condition, maybe something else too?).
> Then find sub-expressions of those that are not of the form 'E op F'
> where 'op' is a comparison operator (==, !=, <=, ...).
> And finally depending on whether they are pointer or integer and
> whether they are negated, replace them with the above constructs (x != 0,
> etc.)
>
> Is this the right way to think about this? Meaning does it fit the mental
> model
> of Coccinelle, or some other approach is needed? (E.g. it crossed my mind to
> maybe match all expressions and try to filter out "unwanted" ones via
> position p != { ... } constraints but that seemed infeasible.)
I think you can do
A simple approach could be:
@@
idexpression *x;
@@
- x
+ (x != NULL)
|| ...
@@
idexpression x;
@@
- x
+ (x != 0)
|| ...
If you want to do function calls, you could do
@@
expression *e;
identifier f;
expression list es;
@@
- f(es)@e
+ (f(es) != NULL)
|| ...
@@
identifier f;
expression list es;
@@
- f(es)
+ (f(es) != 0)
|| ...
Some explanation:
* For pattern || ... there is an isomorphism that allows the pattern to
appear anywhere in the top level of a chain of ||s, including an empty
chain. So it actually should match any expression in a boolean context.
* In the third rule, there is )@e. That means that e should match the
smallest expression that contains the ), which turns out to the be
function call. That way you can talk about the return type of the
function call. A limitation here is that Coccinelle has to be able to
figure out what the type is (this is also a limitation of the first rule
above). If it can't figure out the type of the variable or the return
type of the function call, then the first/third rule will fail and you
will end up with a != 0 test on a pointer. To try to avoid this, you can
use the options --recursive-includes --use-headers-for-types
--relax-include-path to try to take into account as many header files as
possible.
An alternate approach is indeed to do something with position variables.
So you could do something like:
@ok@
position p;
expression e;
expression x;
@@
(x != 0)@e@p
@@
position p != ok.p;
expression x;
@@
- x@p
+ (x != 0)
|| ...
But the first rule would have to be extended to consider lots of cases.
A binary operator metavariable could be helpful, eg:
binary operator bop = { ==, !=, <, > };
julia___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci
[Cocci] getting rid of implicit boolean expressions
Hi,
I'm trying do the following kind of transformations:
int x, y;
char *p;
bool b, c;
-b = x || !y;
+b = (x != 0) || (y == 0);
-c = !p;
+c = (p == NULL);
-if (x & 3)
+if ((x & 3) != 0)
f();
// etc
That is: trying to eliminate implicit boolean-ness (and add parentheses as
well).
I was thinking along the lines of first finding expressions
that are in "boolean context" (part of a || or && expression,
or an if/for/while condition, maybe something else too?).
Then find sub-expressions of those that are not of the form 'E op F'
where 'op' is a comparison operator (==, !=, <=, ...).
And finally depending on whether they are pointer or integer and
whether they are negated, replace them with the above constructs (x != 0,
etc.)
Is this the right way to think about this? Meaning does it fit the mental
model
of Coccinelle, or some other approach is needed? (E.g. it crossed my mind to
maybe match all expressions and try to filter out "unwanted" ones via
position p != { ... } constraints but that seemed infeasible.)
Thanks!
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] [PATCH] Fix parse error in presence of symbols named far
On Wed, 21 Apr 2021, Fuad Tabba wrote:
> Hi,
>
> I just started using Coccinelle yesterday, and I can already see
> it saving me a lot of time and agony. Thank you.
>
> I ran into a problem, and I think that this patch might fix it,
> hopefully without causing other problems. I did some sanity
> checking on my kernel tree, and it seems to be fine.
Thanks very much for this. I have applied the patch.
To check this sort of thing, you can do spatch --parse-c linux_path > old
then make your change
then spatch --parse-c linux_path > new
Then look at the end of old and new. If you successfully parsed more
files and have fewer bad and passed tokens, then all should be good.
julia
>
> There are quite a few variables named "far" in the kernel, e.g.,
> arch/arm64/kvm/inject_fault.c. Coccinelle has special treatment
> for "far" as being linkage related, which causes parse errors in
> their presence. I've grepped for "far" in the kernel tree, and
> haven't noticed where it's used like that, but I could have
> missed it.
>
> To reproduce:
>
> cat > test.c << EOF
> int main(void)
> {
> int far = 0;
> int x;
> x = 10;
> return x;
> }
> EOF
>
> cat > test.cocci << EOF
> @@
> identifier x;
> @@
> - x
> + y
> EOF
>
> spatch --sp-file test.cocci test.c --debug --verbose-parsing
>
> Signed-off-by: Fuad Tabba
> ---
> scripts/coccicheck/cocci/notand.h | 1 -
> standard.h| 1 -
> 2 files changed, 2 deletions(-)
>
> diff --git a/scripts/coccicheck/cocci/notand.h
> b/scripts/coccicheck/cocci/notand.h
> index 3da8c303..91fa6c96 100644
> --- a/scripts/coccicheck/cocci/notand.h
> +++ b/scripts/coccicheck/cocci/notand.h
> @@ -302,7 +302,6 @@
> #define fastcall
> #define asmlinkage
>
> -#define far
> #define SK_FAR
>
> // pb
> diff --git a/standard.h b/standard.h
> index 7a7f96ea..936b19c3 100644
> --- a/standard.h
> +++ b/standard.h
> @@ -298,7 +298,6 @@
> #define fastcall
> #define asmlinkage
>
> -#define far
> #define SK_FAR
>
> // pb
> --
> 2.31.1.368.gbe11c130af-goog
>
> ___
> Cocci mailing list
> Cocci@systeme.lip6.fr
> https://systeme.lip6.fr/mailman/listinfo/cocci
>___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci
[Cocci] [PATCH] Fix parse error in presence of symbols named far
Hi,
I just started using Coccinelle yesterday, and I can already see
it saving me a lot of time and agony. Thank you.
I ran into a problem, and I think that this patch might fix it,
hopefully without causing other problems. I did some sanity
checking on my kernel tree, and it seems to be fine.
There are quite a few variables named "far" in the kernel, e.g.,
arch/arm64/kvm/inject_fault.c. Coccinelle has special treatment
for "far" as being linkage related, which causes parse errors in
their presence. I've grepped for "far" in the kernel tree, and
haven't noticed where it's used like that, but I could have
missed it.
To reproduce:
cat > test.c << EOF
int main(void)
{
int far = 0;
int x;
x = 10;
return x;
}
EOF
cat > test.cocci << EOF
@@
identifier x;
@@
- x
+ y
EOF
spatch --sp-file test.cocci test.c --debug --verbose-parsing
Signed-off-by: Fuad Tabba
---
scripts/coccicheck/cocci/notand.h | 1 -
standard.h| 1 -
2 files changed, 2 deletions(-)
diff --git a/scripts/coccicheck/cocci/notand.h
b/scripts/coccicheck/cocci/notand.h
index 3da8c303..91fa6c96 100644
--- a/scripts/coccicheck/cocci/notand.h
+++ b/scripts/coccicheck/cocci/notand.h
@@ -302,7 +302,6 @@
#define fastcall
#define asmlinkage
-#define far
#define SK_FAR
// pb
diff --git a/standard.h b/standard.h
index 7a7f96ea..936b19c3 100644
--- a/standard.h
+++ b/standard.h
@@ -298,7 +298,6 @@
#define fastcall
#define asmlinkage
-#define far
#define SK_FAR
// pb
--
2.31.1.368.gbe11c130af-goog
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci
