From: Alejandro Colomar <alx@kernel.org>
To: Markus Elfring <Markus.Elfring@web.de>
Cc: cocci@inria.fr, Julia Lawall <Julia.Lawall@inria.fr>,
Nicolas Palix <nicolas.palix@imag.fr>,
Kees Cook <kees@kernel.org>, LKML <linux-kernel@vger.kernel.org>,
kernel-janitors@vger.kernel.org
Subject: Re: [PATCH v2] scripts/coccinelle: Add script for using ARRAY_END()
Date: Mon, 9 Mar 2026 15:32:20 +0100 [thread overview]
Message-ID: <aa7XD-rk_KWQvTQX@devuan> (raw)
In-Reply-To: <806bcb6d-3ebb-4454-973c-f9d6530a17c2@web.de>
[-- Attachment #1: Type: text/plain, Size: 3846 bytes --]
Hi Markus,
On 2026-03-09T15:05:08+0100, Markus Elfring wrote:
> …
> > ---
> > scripts/coccinelle/misc/array_end.cocci | 74 +++++++++++++++++++++++++
> …
>
> Some contributors would appreciate patch version descriptions.
> https://lore.kernel.org/all/?q=%22This+looks+like+a+new+version+of+a+previously+submitted+patch%22
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v7.0-rc3#n310
I replied to all of your comments, and said how I would address them, in
reply to v1. This v2 is in-reply-to v1, so that that sub-thread is easy
to find. And at the bottom is a range-diff where you can find all the
exact changes from v1 to v2.
I could have noted in plain English the changes from v1 to v2, but
I thought it might be a bit redundant.
> May a subdirectory name be omitted from the subject prefix?
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/log/scripts/coccinelle/
Yeah, we could do that. Here's what I checked for writing the subject
prefix:
$ git log --oneline --author Lawall torvalds/master scripts/coccinelle/misc/
f01701ce update Coccinelle URL
92b2dada scripts/coccinelle: drop bugon.cocci
c3003315 scripts: coccinelle: boolinit: drop warnings on named constants
518d8a56 scripts: coccinelle: Correct warning message
b825b432 scripts: coccinelle: only suggest true/false in files that already use>
937c812d coccinelle: orplus: reorganize to improve performance
69c4907b Coccinelle: use false positive annotation
f75621c6 coccinelle: bugon: reduce rule applicability
c7eaa887 Coccinelle: array_size: reduce rule applicability
8f551bef Coccinelle: reduce rule applicability
74a8478f coccinelle: misc: move constants to the right
932058a5 coccinelle: misc: semantic patch to delete overly complex return code >
24f0c2d6 scripts/coccinelle: find constant additions that could be bit ors
ad99ac2f scripts/coccinelle/misc/warn.cocci: use WARN
2cbd0825 scripts/coccinelle: sizeof of pointer
4619c2b8 scripts/coccinelle: address test is always true
89910581 coccinelle: semantic patch for bool issues
4a05f067 coccinelle: semantic patch to check for PTR_ERR after reassignment
29a36d4d scripts/coccinelle: improve the coverage of some semantic patches
a1087ef6 scripts/coccinelle: update for compatability with Coccinelle 0.2.4
Since the latest line and a decent amount of lines have
"scripts/coccinelle", I picked that. I don't have a preference, so
please let me know what's the preferred one. I tend to prefer more
explicit ones, even if slightly longer, but I'll take whatever the
maintainers' preference is.
The only one I didn't really like was the 'scripts: coccinelle:' one.
Paths are more readable if we're going to include all the
subdirectories. But this is just my opinion.
> …
> > +// Comments: No known false positives, but has a few false negatives
>
> Would such information motivate for any further software refinements?
Yes, if anyone here knows how to handle the false negatives and wants to
work with me on improving those, I'm very interested.
Here's one case which isn't caught, for example (which I expect will be
difficult to handle, if not impossible):
@@ -2876,7 +2876,7 @@ static struct dentry *proc_##LSM##_attr_dir_lookup(struct
inode *dir, \
{ \
return proc_pident_lookup(dir, dentry, \
LSM##_attr_dir_stuff, \
- LSM##_attr_dir_stuff + ARRAY_SIZE(LSM##_attr_dir_stuff)); \
+ ARRAY_END(LSM##_attr_dir_stuff)); \
} \
\
static const struct inode_operations proc_##LSM##_attr_dir_inode_ops = { \
I could research and find other false negatives.
Cheers,
Alex
--
<https://www.alejandro-colomar.es>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2026-03-09 14:32 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1772752564.git.alx@kernel.org>
[not found] ` <f1c9dff525752dc5a839760269a1c96d6e0870b4.1772752564.git.alx@kernel.org>
2026-03-09 11:17 ` [cocci] [PATCH] scripts/coccinelle: Add script for using ARRAY_END() Markus Elfring
2026-03-09 11:59 ` Julia Lawall
2026-03-09 12:16 ` Alejandro Colomar
2026-03-09 12:10 ` Alejandro Colomar
2026-03-09 12:21 ` Julia Lawall
2026-03-09 12:27 ` Alejandro Colomar
[not found] ` <9fd8d3d1e7ef3efb6e6dae0972dd515ff02e42bd.1773058287.git.alx@kernel.org>
2026-03-09 14:05 ` [PATCH v2] " Markus Elfring
2026-03-09 14:32 ` Alejandro Colomar [this message]
2026-03-15 17:17 ` Alejandro Colomar
2026-03-15 17:54 ` Julia Lawall
2026-03-15 22:05 ` Alejandro Colomar
2026-03-16 7:18 ` [v2] " Markus Elfring
2026-03-16 10:39 ` Alejandro Colomar
2026-03-16 10:46 ` Markus Elfring
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=aa7XD-rk_KWQvTQX@devuan \
--to=alx@kernel.org \
--cc=Julia.Lawall@inria.fr \
--cc=Markus.Elfring@web.de \
--cc=cocci@inria.fr \
--cc=kees@kernel.org \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nicolas.palix@imag.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox