From: "Arthur Brainville (Ybalrid)" <ybalrid@ybalrid.info>
To: Joe Perches <joe@perches.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Andy Whitcroft <apw@canonical.com>,
Greg KH <gregkh@linuxfoundation.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] checkpatch: Avoid suggesting struct definitions should be const
Date: Mon, 10 Apr 2017 20:56:16 +0200 [thread overview]
Message-ID: <20170410185610.GA25170@Leliel> (raw)
In-Reply-To: <0dce709150d712e66f1b90b03827634b53b28085.1491845946.git.joe@perches.com>
On Mon, Apr 10, 2017 at 10:45:55AM -0700, Joe Perches wrote:
> Many structs are generally used const and there is a known list
> of these structs.
>
> struct definitions should not be generally be declared const.
>
> Add a test for the lack of an open brace immediately after the
> struct to avoid definitions.
>
> This avoids the false positive "struct foo should normally be const"
> message only when the open brace is on the same line as the definition.
>
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
> scripts/checkpatch.pl | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 089c974aa3a5..3a1cb9d7474e 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -6090,11 +6090,11 @@ sub process {
> }
>
> # check for various structs that are normally const (ops, kgdb, device_tree)
> +# and avoid what seem like struct definitions 'struct foo {'
> if ($line !~ /\bconst\b/ &&
> - $line =~ /\bstruct\s+($const_structs)\b/) {
> + $line =~ /\bstruct\s+($const_structs)\b(?!\s*\{)/) {
> WARN("CONST_STRUCT",
> - "struct $1 should normally be const\n" .
> - $herecurr);
> + "struct $1 should normally be const\n" . $herecurr);
> }
>
> # use of NR_CPUS is usually wrong
> --
> 2.10.0.rc2.1.g053435c
>
Oh, right... Everything makes sence now!
That output from checkpatch was confusing. Well, at least for that
little newbie that got the weird idea to send a "fix" on some comedi
driver code (me).
(I have to say, that was an interesting experience, and if me sending
that patch made Joe Perches improve checkpatch a tiny little bit, it
wasn't *that* useless... I just hope I did not annoy people too much)
Obviusly, the patch I sent about that staging comedi driver should be
ignored. I'll be a bit more careful when looking at these thing, and
recheck with the coding-style part of the doc.
Regards,
Arthur Brainville
prev parent reply other threads:[~2017-04-10 18:56 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-09 14:28 [PATCH] Staging: comedidev.h comedi_lrange should be const struct Arthur Brainville (Ybalrid)
2017-04-09 16:22 ` kbuild test robot
2017-04-09 19:02 ` Greg KH
2017-04-10 2:51 ` kbuild test robot
2017-04-10 17:45 ` [PATCH] checkpatch: Avoid suggesting struct definitions should be const Joe Perches
2017-04-10 18:56 ` Arthur Brainville (Ybalrid) [this message]
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=20170410185610.GA25170@Leliel \
--to=ybalrid@ybalrid.info \
--cc=akpm@linux-foundation.org \
--cc=apw@canonical.com \
--cc=gregkh@linuxfoundation.org \
--cc=joe@perches.com \
--cc=linux-kernel@vger.kernel.org \
/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