Re: [Cocci] Coccinelle: Length/Size of char array?

On Mon, 2021-08-02 at 19:35 +0200, Julia Lawall wrote: > > On Mon, 2 Aug 2021, Joe Perches wrote: > > > Is it possible to determine the length of a matched char array and use > > the length in a test? > > > > For instance, add something like a test to show o

[Cocci] Coccinelle: Length/Size of char array?

Is it possible to determine the length of a matched char array and use the length in a test? For instance, add something like a test to show only the instances where a src buffer overruns a dest buffer. void foo(void) { char foo[5]; strcpy(foo, "fits"); } it would be useful to

Re: [Cocci] cocci script to convert linux-kernel allocs with BITS_TO_LONGS to bitmap_alloc

On Tue, 2021-07-13 at 23:33 +0200, Julia Lawall wrote: > > > On Fri, 9 Jul 2021, Joe Perches wrote: > > > > Here is a cocci script to convert various types of bitmap allocations > > > > that use BITS_TO_LONGS to the more typical bitmap_alloc functions. > >

Re: [Cocci] cocci script to convert linux-kernel allocs with BITS_TO_LONGS to bitmap_alloc

On Sat, 2021-07-10 at 21:50 +0200, Julia Lawall wrote: > On Fri, 9 Jul 2021, Joe Perches wrote: > > > Here is a cocci script to convert various types of bitmap allocations > > that use BITS_TO_LONGS to the more typical bitmap_alloc functions. > > > > Perhaps so

[Cocci] cocci script to convert linux-kernel allocs with BITS_TO_LONGS to bitmap_alloc

Here is a cocci script to convert various types of bitmap allocations that use BITS_TO_LONGS to the more typical bitmap_alloc functions. Perhaps something like it could be added to scripts/coccinelle. The diff produced by the script is also below. $ cat bitmap_allocs.cocci // typical uses of

Re: [Cocci] linux-kernel janitorial RFP: Mark static arrays as const

On Sun, 2021-03-07 at 20:14 +0100, Julia Lawall wrote: > > On Wed, 3 Mar 2021, Joe Perches wrote: > > > On Wed, 2021-03-03 at 10:41 +0100, Rasmus Villemoes wrote: > > > On 02/03/2021 18.42, Joe Perches wrote: > > > > Here is a possible opportunit

Re: [Cocci] linux-kernel janitorial RFP: Mark static arrays as const

On Tue, 2021-03-02 at 22:41 +0100, Julia Lawall wrote: > > On Tue, 2 Mar 2021, Joe Perches wrote: > > > Here is a possible opportunity to reduce data usage in the kernel. > > Does it actually reduce data usage? Yes, at least for gcc. For instance: $ gcc --version gcc (Ub

Re: [Cocci] linux-kernel janitorial RFP: Mark static arrays as const

On Wed, 2021-03-03 at 10:41 +0100, Rasmus Villemoes wrote: > On 02/03/2021 18.42, Joe Perches wrote: > > Here is a possible opportunity to reduce data usage in the kernel. > > > > $ git grep -P -n '^static\s+(?!const|struct)(?:\w+\s+){1,3}\w+\s*\[\s*\]' > > drivers/ |

[Cocci] linux-kernel janitorial RFP: Mark static arrays as const

Here is a possible opportunity to reduce data usage in the kernel. $ git grep -P -n '^static\s+(?!const|struct)(?:\w+\s+){1,3}\w+\s*\[\s*\]' drivers/ | \ grep -v __initdata | \ wc -l 3250 Meaning there are ~3000 declarations of arrays with what appears to be file static const content that

Re: [Cocci] cocci: missed strlcpy->strscpy conversion?

On Thu, 2020-12-31 at 22:21 +0100, Julia Lawall wrote: > It seems that the problem is not really the for_each, but the * in front > of a "function call" on the left side of an assignment. Without the *, > everything is fine. So it is indeed probably not worth doing anything > about. Maybe a

[Cocci] cocci: missed strlcpy->strscpy conversion?

On Thu, 2020-12-31 at 11:04 -0800, Joe Perches wrote: > strlcpy is deprecated. see: Documentation/process/deprecated.rst > > Change the calls that do not use the strlcpy return value to the > preferred strscpy. > > Done with cocci script: > > @@ > expression e1, e2,

Re: [Cocci] cocci: missed strlcpy->strscpy conversion?

On Thu, 2020-12-31 at 21:27 +0100, Julia Lawall wrote: > On Thu, 31 Dec 2020, Joe Perches wrote: > > On Thu, 2020-12-31 at 11:04 -0800, Joe Perches wrote: > > > strlcpy is deprecated. see: Documentation/process/deprecated.rst > > > > > > Change the calls that

Re: [Cocci] Proposal for a new checkpatch check; matching _set_drvdata() & _get_drvdata()

On Thu, 2020-11-19 at 17:16 +0200, Andy Shevchenko wrote: > On Thu, Nov 19, 2020 at 4:09 PM Alexandru Ardelean > wrote: > > > > Hey, > > > > So, I stumbled on a new check that could be added to checkpatch. > > Since it's in Perl, I'm reluctant to try it. > > > > Seems many drivers got to a

Re: [Cocci] Subject: [RFC] clang tooling cleanups

On Tue, 2020-10-27 at 09:42 -0700, t...@redhat.com wrote: > This rfc will describe > An upcoming treewide cleanup. > How clang tooling was used to programatically do the clean up. > Solicit opinions on how to generally use clang tooling. > > The clang warning -Wextra-semi-stmt produces about 10k

[Cocci] [PATCH V2] checkpatch: Allow --fix removal of unnecessary break statements

switch/case use of break after a return, goto or break is unnecessary. There is an existing warning for the return and goto uses, so add break and a --fix option too. Signed-off-by: Joe Perches --- v2: Add break to matched keyword and change the message to show the matched keyword

Re: [Cocci] [PATCH] checkpatch: Allow --fix removal of unnecessary break statements

On Mon, 2020-10-19 at 05:55 -0700, Tom Rix wrote: > On 10/18/20 1:19 PM, Joe Perches wrote: > > On Sun, 2020-10-18 at 13:07 -0700, Tom Rix wrote: > > > I like! > > [] > > > could add a '|break' here to catch the couple > > [] > > > break; > > &

Re: [Cocci] [PATCH] checkpatch: Allow --fix removal of unnecessary break statements

On Sun, 2020-10-18 at 13:07 -0700, Tom Rix wrote: > I like! [] > could add a '|break' here to catch the couple [] > break; > > break; Unfortunately, checkpatch is really stupid and it wouldn't catch those cases as there are blank lines between the existing consecutive break statements. It would

[Cocci] [PATCH] checkpatch: Allow --fix removal of unnecessary break statements

switch/case use of break after a return or goto is unnecessary. There is an existing warning for these uses, so add a --fix option too. Signed-off-by: Joe Perches --- For today's next, this would remove ~300 instances like: case FOO: return bar; break

Re: [Cocci] [RFC] treewide: cleanup unreachable breaks

On Sat, 2020-10-17 at 20:21 +0200, Julia Lawall wrote: > On Sat, 17 Oct 2020, Joe Perches wrote: > > On Sat, 2020-10-17 at 09:09 -0700, t...@redhat.com wrote: > > > From: Tom Rix > > > > > > This is a upcoming change to clean up a new warning treewide. >

Re: [Cocci] [RFC] treewide: cleanup unreachable breaks

On Sat, 2020-10-17 at 09:09 -0700, t...@redhat.com wrote: > From: Tom Rix > > This is a upcoming change to clean up a new warning treewide. > I am wondering if the change could be one mega patch (see below) or > normal patch per file about 100 patches or somewhere half way by collecting > early

Re: [Cocci] coccinelle: Convert comma to semicolons (was Re: [PATCH] checkpatch: Add test for comma use that should be semicolon)

On Sun, 2020-09-27 at 19:08 +0200, Julia Lawall wrote: > I end up with 208 patches. I'm not sure that sending them all at once > would be a good idea... Last I looked the diffstat for comma -> semicolon was: 234 files changed, 509 insertions(+), 509 deletions(-) So it would be nearly 1 patch

Re: [Cocci] coccinelle: Convert comma to semicolons (was Re: [PATCH] checkpatch: Add test for comma use that should be semicolon)

On Fri, 2020-09-25 at 19:06 +0200, Julia Lawall wrote: > On Thu, 24 Sep 2020, Joe Perches wrote: > > On Thu, 2020-09-24 at 23:53 +0200, Thomas Gleixner wrote: > > > On Thu, Sep 24 2020 at 13:33, Joe Perches wrote: > > > > On Thu, 2020-09-24 at 22:19 +0200, Thomas Gl

Re: [Cocci] coccinelle: Convert comma to semicolons (was Re: [PATCH] checkpatch: Add test for comma use that should be semicolon)

On Thu, 2020-09-24 at 23:53 +0200, Thomas Gleixner wrote: > On Thu, Sep 24 2020 at 13:33, Joe Perches wrote: > > On Thu, 2020-09-24 at 22:19 +0200, Thomas Gleixner wrote: > > > On Sat, Aug 22 2020 at 09:07, Julia Lawall wrote: > > > > On Fri, 21 Aug 2020, Joe Perche

Re: [Cocci] coccinelle: Convert comma to semicolons (was Re: [PATCH] checkpatch: Add test for comma use that should be semicolon)

On Thu, 2020-09-24 at 22:19 +0200, Thomas Gleixner wrote: > On Sat, Aug 22 2020 at 09:07, Julia Lawall wrote: > > On Fri, 21 Aug 2020, Joe Perches wrote: > > > True enough for a general statement, though the coccinelle > > > script Julia provided does not change a single

Re: [Cocci] [PATCH] checkpatch: Warn on self-assignments

On Thu, 2020-09-10 at 12:51 -0700, Kees Cook wrote: > On Sat, Sep 05, 2020 at 10:58:29AM -0700, Joe Perches wrote: > > The uninitialized_var() macro was removed recently via > > commit 63a0895d960a ("compiler: Remove uninitialized_var() macro") > > as it's not a part

[Cocci] [PATCH] checkpatch: Warn on self-assignments

id compiler warnings and as a back-door mechanism to reproduce the old uninitialized_var macro behavior. Signed-off-by: Joe Perches --- scripts/checkpatch.pl | 11 +++ 1 file changed, 11 insertions(+) diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl index 149518d2a6a7..300b2659aab3

Re: [Cocci] transform oddity / bug ?

On Thu, 2020-09-03 at 17:14 +0200, Julia Lawall wrote: > On Wed, 2 Sep 2020, Joe Perches wrote: > > On Wed, 2020-09-02 at 22:46 +0200, Julia Lawall wrote: > > > On Wed, 2 Sep 2020, Joe Perches wrote: > > > > On Sun, 2020-08-30 at 20:41 +0200, Julia Lawall wrote: >

Re: [Cocci] transform oddity / bug ?

On Wed, 2020-09-02 at 23:38 +0200, Julia Lawall wrote: > On Wed, 2 Sep 2020, Joe Perches wrote: > > On Wed, 2020-09-02 at 22:46 +0200, Julia Lawall wrote: > > > On Wed, 2 Sep 2020, Joe Perches wrote: > > > > On Sun, 2020-08-30 at 20:41 +0200, Julia Lawall wrote: >

Re: [Cocci] transform oddity / bug ?

On Wed, 2020-09-02 at 22:46 +0200, Julia Lawall wrote: > > On Wed, 2 Sep 2020, Joe Perches wrote: > > > On Sun, 2020-08-30 at 20:41 +0200, Julia Lawall wrote: > > > On Sun, 30 Aug 2020, Joe Perches wrote: > > > > On Sun, 2020-08-30 at 17:46 +0200, Julia L

Re: [Cocci] transform oddity / bug ?

On Sun, 2020-08-30 at 20:41 +0200, Julia Lawall wrote: > On Sun, 30 Aug 2020, Joe Perches wrote: > > On Sun, 2020-08-30 at 17:46 +0200, Julia Lawall wrote: > > > Unfortunately this does not work when the declaration > > is comma terminated and not semicolon terminated.

[Cocci] checkpatch? (was: Re: [PATCH v3] coccinelle: misc: add uninitialized_var.cocci script)

On Tue, 2020-09-01 at 12:48 +0300, Denis Efremov wrote: > uninitialized_var() macro was removed from the sources [1] and > other warning-silencing tricks were deprecated [2]. The purpose of this > cocci script is to prevent new occurrences of uninitialized_var() > open-coded variants. > +( > +* T

Re: [Cocci] transform oddity / bug ?

On Sun, 2020-08-30 at 17:46 +0200, Julia Lawall wrote: > The following: > > @not_int_not_len exists@ > type T != int; > identifier x != len; > position p; > identifier sysfs =~ "^sysfs_emit.*$"; > assignment operator aop; > @@ > > T@p x; > ... > x aop sysfs(...) > > @@ > type not_int_not_len.T;

Re: [Cocci] transform oddity / bug ?

On Sun, 2020-08-30 at 17:46 +0200, Julia Lawall wrote: > [...] > > > Thanks, I used the slightly different from your suggestion > > where sysfs is an identifier with function args and a > > semicolon after the transform type, (otherwise I get cocci errors). > > like this below: > > > > But it

Re: [Cocci] transform oddity / bug ?

On Sun, 2020-08-30 at 10:27 +0200, Julia Lawall wrote: > > On Sun, 30 Aug 2020, Joe Perches wrote: > > > On Sun, 2020-08-30 at 08:57 +0200, Julia Lawall wrote: > > > On Sat, 29 Aug 2020, Joe Perches wrote: > > > > > > > Is it me not understanding

Re: [Cocci] transform oddity / bug ?

On Sun, 2020-08-30 at 08:57 +0200, Julia Lawall wrote: > > On Sat, 29 Aug 2020, Joe Perches wrote: > > > Is it me not understanding cocci grammar again? > > The problem is the loop. You are trying to change something in the body > of a loop and the body of a for lo

[Cocci] transform oddity / bug ?

Is it me not understanding cocci grammar again? Given these input and cocci script files: Why isn't the show_test1 function transformed? Why is only the show_test2 function transformed? The only difference between the files is some commented out lines with a for loop and if test. $ cat test.c

Re: [Cocci] [RFC PATCH] coccinelle: misc: add uninitialized_var.cocci script

On Sat, 2020-08-29 at 21:36 +0200, Julia Lawall wrote: > > On Wed, 12 Aug 2020, Denis Efremov wrote: > > > Commit 63a0895d960a ("compiler: Remove uninitialized_var() macro") and > > commit 4b19bec97c88 ("docs: deprecated.rst: Add uninitialized_var()") > > removed uninitialized_var() and

Re: [Cocci] [PATCH] usb: atm: don't use snprintf() for sysfs attrs

On Fri, 2020-08-28 at 01:10 -0700, Joe Perches wrote: > On Fri, 2020-08-28 at 00:58 -0700, Kees Cook wrote: > > On Thu, Aug 27, 2020 at 09:12:06PM -0700, Joe Perches wrote: > > > Perhaps something like the below with a sample conversion > > > that uses single a

Re: [Cocci] [PATCH] usb: atm: don't use snprintf() for sysfs attrs

On Fri, 2020-08-28 at 00:58 -0700, Kees Cook wrote: > On Thu, Aug 27, 2020 at 09:12:06PM -0700, Joe Perches wrote: > > Perhaps something like the below with a sample conversion > > that uses single and multiple sysfs_emit uses. > > On quick review, I like it. :) > >

Re: [Cocci] [PATCH] usb: atm: don't use snprintf() for sysfs attrs

On Thu, 2020-08-27 at 15:45 -0700, Joe Perches wrote: > On Thu, 2020-08-27 at 15:20 -0700, Kees Cook wrote: > > On Fri, Aug 28, 2020 at 12:01:34AM +0300, Denis Efremov wrote: > > > Just FYI, I've send an addition to the device_attr_show.cocci script[1] > > > to turn >

Re: [Cocci] [PATCH] usb: atm: don't use snprintf() for sysfs attrs

On Fri, 2020-08-28 at 01:38 +0300, Denis Efremov wrote: > > This will match it (the difference is in the ';'): thanks. ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] [PATCH] usb: atm: don't use snprintf() for sysfs attrs

On Thu, 2020-08-27 at 15:20 -0700, Kees Cook wrote: > On Fri, Aug 28, 2020 at 12:01:34AM +0300, Denis Efremov wrote: > > Just FYI, I've send an addition to the device_attr_show.cocci script[1] to > > turn > > simple cases of snprintf (e.g. "%i") to sprintf. Looks like many developers > > would >

Re: [Cocci] [PATCH] usb: atm: don't use snprintf() for sysfs attrs

On Thu, 2020-08-27 at 22:03 +, David Laight wrote: > From: Joe Perches > > Sent: 27 August 2020 21:30 > ... > > Perhaps what's necessary is to find any > > appropriate .show function and change > > any use of strcpy/sprintf within those > > function to so

Re: [Cocci] [PATCH] usb: atm: don't use snprintf() for sysfs attrs

On Thu, 2020-08-27 at 23:36 +0200, Julia Lawall wrote: > On Fri, 28 Aug 2020, Denis Efremov wrote: [] > Regarding current device_attr_show.cocci implementation, it detects the > functions > > by declaration: > > ssize_t any_name(struct device *dev, struct device_attribute *attr, char > > *buf) >

Re: [Cocci] [PATCH] usb: atm: don't use snprintf() for sysfs attrs

On Thu, 2020-08-27 at 13:29 -0700, Joe Perches wrote: > On Thu, 2020-08-27 at 21:42 +0200, Julia Lawall wrote: > > On Thu, 27 Aug 2020, Joe Perches wrote: > > > > > On Thu, 2020-08-27 at 15:48 +0100, Alex Dewar wrote: > > > > On Thu, Aug 27, 2020 at 03:4

Re: [Cocci] [PATCH] usb: atm: don't use snprintf() for sysfs attrs

On Thu, 2020-08-27 at 21:42 +0200, Julia Lawall wrote: > > On Thu, 27 Aug 2020, Joe Perches wrote: > > > On Thu, 2020-08-27 at 15:48 +0100, Alex Dewar wrote: > > > On Thu, Aug 27, 2020 at 03:41:06PM +0200, Rasmus Villemoes wrote: > > > > On 27/08/2020 15.18

Re: [Cocci] [PATCH] usb: atm: don't use snprintf() for sysfs attrs

On Thu, 2020-08-27 at 15:48 +0100, Alex Dewar wrote: > On Thu, Aug 27, 2020 at 03:41:06PM +0200, Rasmus Villemoes wrote: > > On 27/08/2020 15.18, Alex Dewar wrote: > > > On Thu, Aug 27, 2020 at 09:15:37AM +0200, Greg Kroah-Hartman wrote: > > > > On Thu, Aug 27, 2020 at 08:42:06AM +0200, Rasmus

Re: [Cocci] coccinelle: Convert comma to semicolons (was Re: [PATCH] checkpatch: Add test for comma use that should be semicolon)

On Fri, 2020-08-21 at 23:35 -0400, Valdis Klētnieks wrote: > On Fri, 21 Aug 2020 18:08:08 -0700, Joe Perches said: > > (forwarding on to kernel-janitors/mentees and kernelnewbies) > > > > Just fyi for anyone that cares: > > > > A janitorial task for someone m

Re: [Cocci] coccinelle: Convert comma to semicolons (was Re: [PATCH] checkpatch: Add test for comma use that should be semicolon)

(forwarding on to kernel-janitors/mentees and kernelnewbies) Just fyi for anyone that cares: A janitorial task for someone might be to use Julia's coccinelle script below to convert the existing instances of commas that separate statements into semicolons.

Re: [Cocci] coccinelle: Convert comma to semicolons (was Re: [PATCH] checkpatch: Add test for comma use that should be semicolon)

On Thu, 2020-08-20 at 19:03 +0200, Julia Lawall wrote: > > > I have a bunch of variations of this that are more complicated than I > > > would have expected. One shorter variant that I have is: > > > > > > @@ > > > expression e1,e2; > > > statement S; > > > @@ > > > > > > S > > > e1 > > > -,

Re: [Cocci] coccinelle: Convert comma to semicolons (was Re: [PATCH] checkpatch: Add test for comma use that should be semicolon)

On Thu, 2020-08-20 at 10:33 +0200, Julia Lawall wrote: > On Wed, 19 Aug 2020, Joe Perches wrote: > > On Wed, 2020-08-19 at 14:22 -0700, Joe Perches wrote: > > > There are commas used as statement terminations that should typically > > > have used semicolons instead. Onl

[Cocci] coccinelle: Convert comma to semicolons (was Re: [PATCH] checkpatch: Add test for comma use that should be semicolon)

On Wed, 2020-08-19 at 14:22 -0700, Joe Perches wrote: > There are commas used as statement terminations that should typically > have used semicolons instead. Only direct assignments or use of a single > function or value on a single line are detected by this test. > > e.g.: &g

Re: [Cocci] [PATCH] coccinelle: api: add kzfree script

On Sun, 2020-06-14 at 22:42 +0300, Denis Efremov wrote: > On 6/4/20 7:27 PM, Joe Perches wrote: > > On Thu, 2020-06-04 at 17:08 +0300, Denis Efremov wrote: > > > Check for memset() with 0 followed by kfree(). > > > > Perhaps those uses should be memzer

Re: [Cocci] [PATCH] coccinelle: api: add kzfree script

On Thu, 2020-06-04 at 17:08 +0300, Denis Efremov wrote: > Check for memset() with 0 followed by kfree(). Perhaps those uses should be memzero_explicit or kvfree_sensitive. ___ Cocci mailing list Cocci@systeme.lip6.fr

Re: [Cocci] [PATCH] coccinelle: api: add kzfree script

On Thu, 2020-06-04 at 20:30 +0300, Denis Efremov wrote: > > On 6/4/20 7:27 PM, Joe Perches wrote: > > On Thu, 2020-06-04 at 17:08 +0300, Denis Efremov wrote: > > > Check for memset() with 0 followed by kfree(). > > > > Perhaps those uses should be mem

Re: [Cocci] [PATCH -next] iwlwifi: pcie: Use bitwise instead of arithmetic operator for flags

On Wed, 2020-05-06 at 16:51 +0300, Luciano Coelho wrote: > On Tue, 2020-05-05 at 20:19 -0700, Joe Perches wrote: > > On Wed, 2020-05-06 at 11:07 +0800, Samuel Zou wrote: > > > This silences the following coccinelle warning: > > > > > > "WARNING: sum of

Re: [Cocci] [PATCH v2 2/2] crypto: Remove unnecessary memzero_explicit()

On Tue, 2020-04-14 at 15:37 -0400, Waiman Long wrote: > OK, I can change it to clear the key length when the allocation failed > which isn't likely. Perhaps: kfree_sensitive(op->key); op->key = NULL; op->keylen = 0; but I don't know that it impacts any possible state.

Re: [Cocci] [PATCH 2/2] crypto: Remove unnecessary memzero_explicit()

On Mon, 2020-04-13 at 17:15 -0400, Waiman Long wrote: > Since kfree_sensitive() will do an implicit memzero_explicit(), there > is no need to call memzero_explicit() before it. Eliminate those > memzero_explicit() and simplify the call sites. 2 bits of trivia: > diff --git

Re: [Cocci] linux: bad logic in repetitive tests

On Tue, 2020-03-31 at 10:50 +0200, Julia Lawall wrote: > On Mon, 30 Mar 2020, Joe Perches wrote: > > > There is a block of if tests against the same variable > > in include/linux/mtd/pfow.h that likely is defective > > > > if (prog_status & 0x3) > &

Re: [Cocci] linux: special logic in repetitive tests

On Tue, 2020-03-31 at 08:28 +0200, Markus Elfring wrote: > > There is a block of if tests against the same variable > > in include/linux/mtd/pfow.h that likely is defective > > I wonder about this interpretation. Wonder harder. If something is (& 3) it is also either (& 2 || & 1) so why have

[Cocci] linux: bad logic in repetitive tests

There is a block of if tests against the same variable in include/linux/mtd/pfow.h that likely is defective if (prog_status & 0x3) ... else if (prog_status & 0x2) ... else (prog_status & 0x1) ... If the first test is true

Re: [Cocci] [PATCH] net: Zeroing the structure ethtool_wolinfo in ethtool_get_wol()

On Sat, 2019-10-26 at 15:54 +0800, zhanglin wrote: > memset() the structure ethtool_wolinfo that has padded bytes > but the padded bytes have not been zeroed out. [] > diff --git a/net/core/ethtool.c b/net/core/ethtool.c [] > @@ -1471,11 +1471,13 @@ static int ethtool_reset(struct net_device *dev,

Re: coccinelle: api/devm_platform_ioremap_resource: remove useless script

On Sat, 2019-10-19 at 21:43 +0100, Marc Zyngier wrote: > Providing Coccinelle scripts that scream about perfectly valid code is > pointless, and the result is actively harmful. Doubtful. If the new code is smaller object code and correct than the conversion is worthwhile. fyi: There are

Re: [PATCH] scripts: coccinelle: check for !(un)?likely usage

On Wed, 2019-08-28 at 13:33 +0200, Rasmus Villemoes wrote: > On 25/08/2019 21.19, Julia Lawall wrote: > > > On 26 Aug 2019, at 02:59, Denis Efremov wrote: > > > > On 25.08.2019 19:37, Joe Perches wrote: > > > > > On Sun, 2019-08-25 at 16:05 +0300, Denis E

Re: [PATCH] scripts: coccinelle: check for !(un)?likely usage

On Sun, 2019-08-25 at 16:05 +0300, Denis Efremov wrote: > This patch adds coccinelle script for detecting !likely and !unlikely > usage. It's better to use unlikely instead of !likely and vice versa. Please explain _why_ is it better in the changelog. btw: there are relatively few uses like this

Re: [Cocci] [Fwd: [PATCH 1/2] string: Add stracpy and stracpy_pad mechanisms]

On Mon, 2019-07-29 at 10:07 -0400, Julia Lawall wrote: > I see that stracpy is now in linux-next. Would it be reasonable to send > patches adding uses now? My preference would be to have: o A provably correct script If a small subset of possible conversions are skipped, that's fine. o As

Re: [Fwd: [PATCH 1/2] string: Add stracpy and stracpy_pad mechanisms]

On Thu, 2019-07-25 at 08:58 -0500, Julia Lawall wrote: > On Thu, 25 Jul 2019, Joe Perches wrote: [] > > Just for completeness and correctness, as I at > > least don't find an existing use: > > > > Perhaps this "x =" should also include += and

Re: [Fwd: [PATCH 1/2] string: Add stracpy and stracpy_pad mechanisms]

On Wed, 2019-07-24 at 20:42 -0500, Julia Lawall wrote: > New version. I check for non-use of the return value of strlcpy and > address some issues that affected the matching of the case where the first > argument involves a pointer dereference. Actually, an isomorphism now > takes care of that

Re: [Fwd: [PATCH 1/2] string: Add stracpy and stracpy_pad mechanisms]

On Wed, 2019-07-24 at 10:28 +, David Laight wrote: > From: Joe Perches > > Sent: 24 July 2019 05:38 > > On Tue, 2019-07-23 at 23:27 -0500, Julia Lawall wrote: > > > On Tue, 23 Jul 2019, Joe Perches wrote: > > > > On Tue, 2019-07-23 at 22:54 -0500, Julia Law

Re: [Fwd: [PATCH 1/2] string: Add stracpy and stracpy_pad mechanisms]

On Tue, 2019-07-23 at 23:27 -0500, Julia Lawall wrote: > > On Tue, 23 Jul 2019, Joe Perches wrote: > > > On Tue, 2019-07-23 at 22:54 -0500, Julia Lawall wrote: > > > A seantic patch and the resulting output for the case where the third > > > arugument is

Re: [Fwd: [PATCH 1/2] string: Add stracpy and stracpy_pad mechanisms]

On Tue, 2019-07-23 at 22:54 -0500, Julia Lawall wrote: > A seantic patch and the resulting output for the case where the third > arugument is a constant is attached. Likewise the resulting output on a > recent linux-next. > > julia Nice. Thanks Julia A couple issues: There is a problem with

Re: [Fwd: [PATCH 1/2] string: Add stracpy and stracpy_pad mechanisms]

On Tue, 2019-07-23 at 15:52 -0500, Julia Lawall wrote: > On Mon, 22 Jul 2019, Joe Perches wrote: > > I just sent a patch to add yet another string copy mechanism. > > > > This could help avoid misuses of strscpy and strlcpy like this > > patch set: > > >

[Cocci] [Fwd: [PATCH 1/2] string: Add stracpy and stracpy_pad mechanisms]

like u8 or unsigned char. A BUILD_BUG is emitted when the type of to is not compatible. Signed-off-by: Joe Perches --- include/linux/string.h | 41 + 1 file changed, 41 insertions(+) diff --git a/include/linux/string.h b/include/linux/string.h index

Re: [Cocci] [Fwd: Re: [PATCH] rtc: sun6i: Use struct_size() in kzalloc()]

On Thu, 2018-08-23 at 15:27 -0700, Kees Cook wrote: > On Thu, Aug 23, 2018 at 3:21 PM, Joe Perches wrote: > > On Thu, 2018-08-23 at 18:13 -0400, Julia Lawall wrote: > > > > > > On Thu, 23 Aug 2018, Kees Cook wrote: > > > > > > (a + b

Re: [Cocci] [Fwd: Re: [PATCH] rtc: sun6i: Use struct_size() in kzalloc()]

On Thu, 2018-08-23 at 20:17 -0400, Julia Lawall wrote: > > On Thu, 23 Aug 2018, Joe Perches wrote: > > > On Thu, 2018-08-23 at 15:27 -0700, Kees Cook wrote: > > > On Thu, Aug 23, 2018 at 3:21 PM, Joe Perches wrote: > > > > On Thu, 2018-08-2

Re: [Cocci] [Fwd: Re: [PATCH] rtc: sun6i: Use struct_size() in kzalloc()]

On Thu, 2018-08-23 at 18:13 -0400, Julia Lawall wrote: > > On Thu, 23 Aug 2018, Kees Cook wrote: > > > On Thu, Aug 23, 2018 at 3:00 PM, Julia Lawall wrote: > > > > > > > > > On Thu, 23 Aug 2018, Kees Cook wrote: > > > > >

Re: [Cocci] [PATCH v2 net] nfp: cast sizeof() to int when comparing with error code

On Tue, 2018-06-26 at 09:16 +0800, Chengguang Xu wrote: > sizeof() will return unsigned value so in the error check > negative error code will be always larger than sizeof(). This looks like a general class of error in the kernel where a signed result that could be returning a -errno is tested

Re: [Cocci] [PATCH v2 2/2] hwmon: npcm750: add NPCM7xx PWM and Fan driver

On Thu, 2018-06-21 at 15:17 +0200, Julia Lawall wrote: > On Wed, 20 Jun 2018, Joe Perches wrote: > > Also, spatch (1.0.4) seems to have a defect for this > > when the type is used in operations that change a > > smaller type to int or unsigned int. > > > > i.e

Re: [Cocci] check for non-const arguments used only as const accesses

On Mon, 2018-06-11 at 23:23 +0200, Julia Lawall wrote: > On Mon, 11 Jun 2018, Joe Perches wrote: > > Many times it would be useful to update functions > > where non-const arguments are used only as const > > dereferences or as arguments to other function that > > use con

[Cocci] check for non-const arguments used only as const accesses

Many times it would be useful to update functions where non-const arguments are used only as const dereferences or as arguments to other function that use const. Is it possible for coccinelle to find and show these types of uses that could be const? e.g. int foo(int val, u8 *a, int index) {

Re: [Cocci] [PATCH] crypto: cavium: zip: Remove unnecessary parentheses

On Thu, 2018-03-29 at 21:03 +0530, Varsha Rao wrote: > On Wed, Mar 28, 2018 at 11:41 PM, Joe Perches wrote: > > > > On Wed, 2018-03-28 at 23:27, Varsha Rao wrote: > > > This patch fixes the clang warning of extraneous parentheses, with the > >

Re: [Cocci] [PATCH] crypto: cavium: zip: Remove unnecessary parentheses

On Wed, 2018-03-28 at 23:27 +0530, Varsha Rao wrote: > This patch fixes the clang warning of extraneous parentheses, with the > following coccinelle script. > > @@ > identifier i; > constant c; > @@ > ( > -((i == c)) > +i == c > > > > -((i <= c)) > +i <= c Why just the "==" and "<=" cases? Why

[Cocci] coccinelle & linux-kernel: unindent blocks by reversing tests?

There are many blocks of code that could be unindented and so neatened by reversing tests. For instance, here are linux-kernel void functions with deep indentation at the end of the function definition. These functions are all similar to: void foo(...) { [code...] if (foo) {

Re: [Cocci] coccinelle & linux-kernel: unindent blocks by reversing tests?

On Sun, 2018-03-18 at 18:50 +0100, Julia Lawall wrote: > > On Sun, 18 Mar 2018, Joe Perches wrote: > > > There are many blocks of code that could be > > unindented and so neatened by reversing tests. [] > > Which often saves many vertical lines by reducing > > n

Re: [Cocci] [PATCH v2 0/5] Support for generalized use of make C={1, 2} via a wrapper program

On Mon, 2017-12-18 at 10:46 -0700, Jason Gunthorpe wrote: > On Sun, Dec 17, 2017 at 10:00:17PM -0800, Joe Perches wrote: > > > > Today when we run checkers we get so many warnings it is too hard to > > > make any sense of it. > > > > Here is a list of

Re: [Cocci] [PATCH v2 0/5] Support for generalized use of make C={1, 2} via a wrapper program

On Mon, 2017-12-18 at 14:05 +0100, Knut Omang wrote: > > Here is a list of the checkpatch messages for drivers/infiniband > > sorted by type. > > > > Many of these might be corrected by using > > > > $ ./scripts/checkpatch.pl -f --fix-inplace --types= \ > > $(git ls-files drivers/infiniband/)

Re: [Cocci] [PATCH v2 0/5] Support for generalized use of make C={1, 2} via a wrapper program

On Sun, 2017-12-17 at 22:00 -0700, Jason Gunthorpe wrote: > On Sun, Dec 17, 2017 at 03:14:10AM +0100, Knut Omang wrote: > > > > I like the ability to add more checkers and keep then in the main > > > upstream tree. But adding overrides for specific subsystems goes against > > > the policy that

Re: [Cocci] [PATCH v2 0/5] Support for generalized use of make C={1, 2} via a wrapper program

On Sat, 2017-12-16 at 17:27 +0100, Knut Omang wrote: > On Sat, 2017-12-16 at 07:21 -0800, Joe Perches wrote: > > On Sat, 2017-12-16 at 15:42 +0100, Knut Omang wrote: > > > This patch series implements features to make it easier to run checkers > > > on the > > >

Re: [Cocci] [PATCH v2 0/5] Support for generalized use of make C={1, 2} via a wrapper program

On Sat, 2017-12-16 at 09:47 -0800, Stephen Hemminger wrote: > On Sat, 16 Dec 2017 15:42:25 +0100 > Knut Omang wrote: > > > This patch series implements features to make it easier to run checkers on > > the > > entire kernel as part of automatic and developer testing. > >

Re: [Cocci] [PATCH v2 0/5] Support for generalized use of make C={1, 2} via a wrapper program

On Sat, 2017-12-16 at 15:42 +0100, Knut Omang wrote: > This patch series implements features to make it easier to run checkers on the > entire kernel as part of automatic and developer testing. This seems like a useful and reasonable series, thanks. Do please take Julia's grammar updates. How is

Re: [Cocci] [PATCH] net: usb: hso.c: remove unneeded DRIVER_LICENSE #define

On Thu, 2017-11-23 at 15:30 -0800, Joe Perches wrote: > --- /dev/null 2017-11-23 06:19:12.943046739 -0800 > +++ single_use_module.pl 2017-11-23 15:23:11.729812156 -0800 > @@ -0,0 +1,15 @@ [] > +$data =~ s~$var~$string~; this needs to be: $data =~ s~\b$v

Re: [Cocci] [PATCH] net: usb: hso.c: remove unneeded DRIVER_LICENSE #define

On Fri, 2017-11-17 at 15:19 +0100, Greg Kroah-Hartman wrote: > There is no need to #define the license of the driver, just put it in > the MODULE_LICENSE() line directly as a text string. > > This allows tools that check that the module license matches the source > code license to work properly,

Re: [Cocci] [PATCH] coccinelle: flags.cocci: reorganize patterns to improve efficiency

On Wed, 2017-11-15 at 22:55 +0100, Julia Lawall wrote: > What version of Coccinelle do you have? > > I tried 1.0.4 and 1.0.6, > > but both failed. > For me, it also fails for 1.0.6. It should be OK for 1.0.7. Then likely this patch should not be applied or some form of local version checking

Re: [Cocci] [PATCH] coccinelle: api: detect duplicate chip data arrays

On Thu, 2017-10-05 at 21:40 +0200, Julia Lawall wrote: > On Thu, 5 Oct 2017, Joe Perches wrote: > > btw: spatch 1.7 doesn't seem to have a tag in git > > > > From the script: > > > > // Requires: 1.0.7 > > > > Assuming this is correct, then

Re: [Cocci] [PATCH] coccinelle: api: detect duplicate chip data arrays

On Thu, 2017-10-05 at 21:19 +0200, Julia Lawall wrote: > On Thu, 5 Oct 2017, Joe Perches wrote: > > On Thu, 2017-10-05 at 21:13 +0200, Julia Lawall wrote: > > > On Fri, 6 Oct 2017, Masahiro Yamada wrote: > > > > 2017-10-01 21:42 GMT+09:00 Juli

Re: [Cocci] [PATCH] coccinelle: api: detect duplicate chip data arrays

On Thu, 2017-10-05 at 12:46 -0700, Liam Breck wrote: > Hi Joe, > > On Thu, Oct 5, 2017 at 12:30 PM, Joe Perches <j...@perches.com> wrote: > > On Thu, 2017-10-05 at 21:19 +0200, Julia Lawall wrote: > > > On Thu, 5 Oct 2017, Joe Perches wrote: > > > > On Th

Re: [Cocci] cocci script to add static to const declarations ?

On Thu, 2017-08-31 at 21:25 +0200, Julia Lawall wrote: > On Thu, 31 Aug 2017, Joe Perches wrote: > > On Thu, 2017-08-31 at 16:22 +0200, Julia Lawall wrote: > > > On Wed, 30 Aug 2017, Joe Perches wrote: > > > > fyi: This doesn't find const structs that could be static

Re: [Cocci] cocci script to add static to const declarations ?

On Thu, 2017-08-31 at 16:22 +0200, Julia Lawall wrote: > On Wed, 30 Aug 2017, Joe Perches wrote: > > fyi: This doesn't find const structs that could be static. > > > > Things like: drivers/gpu/drm/i915/selftests/i915_vma.c > > [] > > static int igt_vma_rotate(void

Re: [Cocci] cocci script to add static to const declarations ?

On Wed, 2017-08-30 at 23:41 +0200, Julia Lawall wrote: > New version. Thanks. fyi: This doesn't find const structs that could be static. Things like: drivers/gpu/drm/i915/selftests/i915_vma.c [] static int igt_vma_rotate(void *arg) { [] const struct intel_rotation_plane_info planes[] =

Re: [Cocci] cocci script to add static to const declarations ?

On Wed, 2017-08-30 at 13:41 +0200, Julia Lawall wrote: > The following seems to work: > > @initialize:ocaml@ > @@ > > let diff(p,i) = not ((List.hd p).current_element = i) > > @promising disable optional_storage@ > position p; > constant c; > type t; > identifier i; > @@ > > const t i@p[] = {

  1   2   >