From: Joe Perches <joe@perches.com>
To: jim.cromie@gmail.com
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/3] checkpatch: tweak extern in C warning
Date: Wed, 30 Jun 2021 10:33:23 -0700 [thread overview]
Message-ID: <d3cf5de00a7ac017ae70d4cba58c1d93defd5491.camel@perches.com> (raw)
In-Reply-To: <CAJfuBxz7DMfFOwyvUvN7F9Jc=meQs7ro5OFhiycq1GxMNHRPzw@mail.gmail.com>
On Sat, 2021-06-26 at 21:47 -0600, jim.cromie@gmail.com wrote:
> On Sat, Jun 26, 2021 at 12:46 PM Joe Perches <joe@perches.com> wrote:
> > On Fri, 2021-06-25 at 21:40 -0600, Jim Cromie wrote:
> > > The extern-in-C rule has one important exception: the symbol is
> > > defined in/by the linker script. By convention, these almost always
> > > contain: _start, _stop, _end. Suppress the warning on such symbols.
> > []
> > > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> > > []
> > > @@ -6910,7 +6910,8 @@ sub process {
> > > $stat =~ /^.\s*extern\s+/)
> > > {
> > > WARN("AVOID_EXTERNS",
> > > - "externs should be avoided in .c files\n" . $herecurr);
> > > + "externs should be avoided in .c files\n($stat)\n" . $herecurr)
> > > + unless $stat =~ /_start|_stop|_end/;
> >
> > nak.
> >
> > As far as I can tell, there's no reason these symbols
> > should not be in .h files.
>
> judging from the codebase, it has been a case-by-case decision,
> with 8/10 of the linker-vars extern'd into C files, not headers.
[]
> > besides that:
> >
> > output is single line, $stat should not be used and
> > using unless is not desired.
> >
>
> could you clarify ?
> style issues are easy, std if form...
> $stat is already used, it must contain extern to get here.
Sure, it's used as part of a test but it's never output as part of
an error message. $stat strips any leading '+' from the 2nd and
subsequent lines.
There's a mechanism used in several other tests to show these lines.
my $cnt = statement_rawlines($stat);
my $herectx = get_stat_here($linenr, $cnt, $here);
with the output of $herectx.
> checking it for a likely-linker-symbol seems fair.
next prev parent reply other threads:[~2021-06-30 17:33 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-26 3:40 [PATCH 0/3] checkpatch tweaks Jim Cromie
2021-06-26 3:40 ` [PATCH 1/3] checkpatch: skip spacing tests on linker scripts Jim Cromie
2021-06-26 4:15 ` Joe Perches
2021-06-28 16:53 ` jim.cromie
2021-06-29 16:48 ` jim.cromie
2021-06-29 18:28 ` Joe Perches
2021-06-29 19:50 ` jim.cromie
2021-06-29 20:01 ` Joe Perches
2021-06-30 16:38 ` jim.cromie
2021-06-30 17:12 ` Joe Perches
2021-06-26 3:40 ` [PATCH 2/3] checkpatch: tweak extern in C warning Jim Cromie
2021-06-26 4:31 ` Joe Perches
2021-06-27 3:47 ` jim.cromie
2021-06-30 17:33 ` Joe Perches [this message]
2021-06-26 3:40 ` [PATCH 3/3] checkpatch: suppress BUG_ON warn when it is named in commitmsg Jim Cromie
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=d3cf5de00a7ac017ae70d4cba58c1d93defd5491.camel@perches.com \
--to=joe@perches.com \
--cc=jim.cromie@gmail.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;
as well as URLs for NNTP newsgroup(s).