From: Julia Lawall <julia.lawall@inria.fr>
To: Markus Elfring <Markus.Elfring@web.de>
Cc: Denis Efremov <efremov@linux.com>,
Coccinelle <cocci@systeme.lip6.fr>,
Gilles Muller <Gilles.Muller@lip6.fr>,
Masahiro Yamada <yamada.masahiro@socionext.com>,
Michal Marek <michal.lkml@markovi.net>,
Nicolas Palix <nicolas.palix@imag.fr>,
linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org
Subject: Re: [PATCH] coccinelle: api: add kvfree script
Date: Sat, 6 Jun 2020 16:39:13 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.21.2006061634130.19534@hadrien> (raw)
In-Reply-To: <119d91fd-1ad0-8842-10eb-ee8fa16da1b0@web.de>
[-- Attachment #1: Type: text/plain, Size: 2012 bytes --]
On Sat, 6 Jun 2020, Markus Elfring wrote:
> > +@choice@
> > +expression E, E1;
> > +position kok, vok;
> > +@@
> > +
> > +(
> > + if (...) {
> > + ...
> > + E = \(kmalloc@kok\|…\)(...)
>
> Further implementation details from this SmPL script caught my software
> development attention.
>
> * Is there a need to add the specification “when any” to the SmPL ellipses
> before such assignment statements?
Having multiple assignments to kmalloc in one if seems unlikely, and
perhaps one would want to think about such a case differently, so it seems
ok as is.
>
> * A limited search approach was expressed. Will additional source code variations
> become relevant?
> + switch statement
> + if branches with single statements
> + conditional operator
The point is that there is a kmalloc in one branch and a vmalloc in
another branch, so a if with a single branch doesn't seem relevant.
The other cases sem highly improbable.
>
> > +@opportunity depends on !patch …@
> …
> > + E = \(kmalloc\|…\)(..., size, ...)
> > + ... when != E = E1
> > + when != size = E1
>
> I wonder that two assignments should be excluded here according to
> the same expression metavariable.
Doesn't matter. The metavariables are considered separately in the
different whens.
>
> +@pkfree depends on patch exists@
> …
> +- \(kfree\|kvfree\)(E)
> ++ vfree(E)
>
> Would you like to use a SmPL code variant like the following
> at any more places?
> (Is it occasionally helpful to increase the change precision?)
>
> +-\(kfree\|kvfree\)
> ++vfree
> + (E)
"increase the change precision" seems to be an obscure way to say "improve
the formatting". Indeed, leaving (E) as is would have the effect of not
changing the formatting. But the problem seems unlikely for a functoin
with such a short name. And this presentation will likely run afoul of
the fact that you can't attach + code to a disjunction. So the original
presentation was more concise, and should be fine in practice.
julia
WARNING: multiple messages have this Message-ID (diff)
From: Julia Lawall <julia.lawall@inria.fr>
To: Markus Elfring <Markus.Elfring@web.de>
Cc: Michal Marek <michal.lkml@markovi.net>,
Gilles Muller <Gilles.Muller@lip6.fr>,
kernel-janitors@vger.kernel.org,
Nicolas Palix <nicolas.palix@imag.fr>,
linux-kernel@vger.kernel.org, Coccinelle <cocci@systeme.lip6.fr>
Subject: Re: [PATCH] coccinelle: api: add kvfree script
Date: Sat, 06 Jun 2020 14:39:13 +0000 [thread overview]
Message-ID: <alpine.DEB.2.21.2006061634130.19534@hadrien> (raw)
In-Reply-To: <119d91fd-1ad0-8842-10eb-ee8fa16da1b0@web.de>
[-- Attachment #1: Type: text/plain, Size: 2012 bytes --]
On Sat, 6 Jun 2020, Markus Elfring wrote:
> > +@choice@
> > +expression E, E1;
> > +position kok, vok;
> > +@@
> > +
> > +(
> > + if (...) {
> > + ...
> > + E = \(kmalloc@kok\|…\)(...)
>
> Further implementation details from this SmPL script caught my software
> development attention.
>
> * Is there a need to add the specification “when any” to the SmPL ellipses
> before such assignment statements?
Having multiple assignments to kmalloc in one if seems unlikely, and
perhaps one would want to think about such a case differently, so it seems
ok as is.
>
> * A limited search approach was expressed. Will additional source code variations
> become relevant?
> + switch statement
> + if branches with single statements
> + conditional operator
The point is that there is a kmalloc in one branch and a vmalloc in
another branch, so a if with a single branch doesn't seem relevant.
The other cases sem highly improbable.
>
> > +@opportunity depends on !patch …@
> …
> > + E = \(kmalloc\|…\)(..., size, ...)
> > + ... when != E = E1
> > + when != size = E1
>
> I wonder that two assignments should be excluded here according to
> the same expression metavariable.
Doesn't matter. The metavariables are considered separately in the
different whens.
>
> +@pkfree depends on patch exists@
> …
> +- \(kfree\|kvfree\)(E)
> ++ vfree(E)
>
> Would you like to use a SmPL code variant like the following
> at any more places?
> (Is it occasionally helpful to increase the change precision?)
>
> +-\(kfree\|kvfree\)
> ++vfree
> + (E)
"increase the change precision" seems to be an obscure way to say "improve
the formatting". Indeed, leaving (E) as is would have the effect of not
changing the formatting. But the problem seems unlikely for a functoin
with such a short name. And this presentation will likely run afoul of
the fact that you can't attach + code to a disjunction. So the original
presentation was more concise, and should be fine in practice.
julia
WARNING: multiple messages have this Message-ID (diff)
From: Julia Lawall <julia.lawall@inria.fr>
To: Markus Elfring <Markus.Elfring@web.de>
Cc: Michal Marek <michal.lkml@markovi.net>,
Gilles Muller <Gilles.Muller@lip6.fr>,
kernel-janitors@vger.kernel.org,
Nicolas Palix <nicolas.palix@imag.fr>,
linux-kernel@vger.kernel.org, Coccinelle <cocci@systeme.lip6.fr>
Subject: Re: [Cocci] [PATCH] coccinelle: api: add kvfree script
Date: Sat, 6 Jun 2020 16:39:13 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.21.2006061634130.19534@hadrien> (raw)
In-Reply-To: <119d91fd-1ad0-8842-10eb-ee8fa16da1b0@web.de>
[-- Attachment #1: Type: text/plain, Size: 2012 bytes --]
On Sat, 6 Jun 2020, Markus Elfring wrote:
> > +@choice@
> > +expression E, E1;
> > +position kok, vok;
> > +@@
> > +
> > +(
> > + if (...) {
> > + ...
> > + E = \(kmalloc@kok\|…\)(...)
>
> Further implementation details from this SmPL script caught my software
> development attention.
>
> * Is there a need to add the specification “when any” to the SmPL ellipses
> before such assignment statements?
Having multiple assignments to kmalloc in one if seems unlikely, and
perhaps one would want to think about such a case differently, so it seems
ok as is.
>
> * A limited search approach was expressed. Will additional source code variations
> become relevant?
> + switch statement
> + if branches with single statements
> + conditional operator
The point is that there is a kmalloc in one branch and a vmalloc in
another branch, so a if with a single branch doesn't seem relevant.
The other cases sem highly improbable.
>
> > +@opportunity depends on !patch …@
> …
> > + E = \(kmalloc\|…\)(..., size, ...)
> > + ... when != E = E1
> > + when != size = E1
>
> I wonder that two assignments should be excluded here according to
> the same expression metavariable.
Doesn't matter. The metavariables are considered separately in the
different whens.
>
> +@pkfree depends on patch exists@
> …
> +- \(kfree\|kvfree\)(E)
> ++ vfree(E)
>
> Would you like to use a SmPL code variant like the following
> at any more places?
> (Is it occasionally helpful to increase the change precision?)
>
> +-\(kfree\|kvfree\)
> ++vfree
> + (E)
"increase the change precision" seems to be an obscure way to say "improve
the formatting". Indeed, leaving (E) as is would have the effect of not
changing the formatting. But the problem seems unlikely for a functoin
with such a short name. And this presentation will likely run afoul of
the fact that you can't attach + code to a disjunction. So the original
presentation was more concise, and should be fine in practice.
julia
[-- Attachment #2: Type: text/plain, Size: 136 bytes --]
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci
next prev parent reply other threads:[~2020-06-06 14:39 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-06 14:04 [PATCH] coccinelle: api: add kvfree script Markus Elfring
2020-06-06 14:04 ` [Cocci] " Markus Elfring
2020-06-06 14:04 ` Markus Elfring
2020-06-06 14:39 ` Julia Lawall [this message]
2020-06-06 14:39 ` [Cocci] " Julia Lawall
2020-06-06 14:39 ` Julia Lawall
2020-06-06 15:10 ` Markus Elfring
2020-06-06 15:10 ` [Cocci] " Markus Elfring
2020-06-06 15:10 ` Markus Elfring
-- strict thread matches above, loose matches on Subject: below --
2020-06-06 7:30 [PATCH] " Markus Elfring
2020-06-06 7:30 ` [Cocci] " Markus Elfring
2020-06-06 7:30 ` Markus Elfring
2020-06-06 7:46 ` Julia Lawall
2020-06-06 7:46 ` [Cocci] " Julia Lawall
2020-06-06 7:46 ` Julia Lawall
2020-06-06 9:50 ` Markus Elfring
2020-06-06 9:50 ` [Cocci] " Markus Elfring
2020-06-06 9:50 ` Markus Elfring
2020-06-07 14:02 ` Coccinelle: Extending capabilities for source file pre-selection Markus Elfring
2020-06-07 14:02 ` [Cocci] " Markus Elfring
2020-06-07 14:02 ` Markus Elfring
2020-06-06 11:06 ` coccinelle: api: add kvfree script Markus Elfring
2020-06-06 11:06 ` [Cocci] " Markus Elfring
2020-06-06 11:06 ` Markus Elfring
2020-06-06 11:11 ` Julia Lawall
2020-06-06 11:11 ` [Cocci] " Julia Lawall
2020-06-06 11:11 ` Julia Lawall
2020-06-06 11:21 ` Markus Elfring
2020-06-06 11:21 ` [Cocci] " Markus Elfring
2020-06-06 11:21 ` Markus Elfring
2020-06-07 6:42 ` Coccinelle: Improving software components around usage of SmPL disjunctions Markus Elfring
2020-06-07 6:42 ` [Cocci] " Markus Elfring
2020-06-07 6:42 ` Markus Elfring
2020-06-05 20:42 [PATCH] coccinelle: api: add kvfree script Denis Efremov
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=alpine.DEB.2.21.2006061634130.19534@hadrien \
--to=julia.lawall@inria.fr \
--cc=Gilles.Muller@lip6.fr \
--cc=Markus.Elfring@web.de \
--cc=cocci@systeme.lip6.fr \
--cc=efremov@linux.com \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michal.lkml@markovi.net \
--cc=nicolas.palix@imag.fr \
--cc=yamada.masahiro@socionext.com \
/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.