From: Andy Whitcroft <apw@shadowen.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: linux-kernel@vger.kernel.org, Andrew Morton <akpm@linux-foundation.org>
Subject: Re: latest checkpatch
Date: Thu, 18 Oct 2007 20:25:21 +0100 [thread overview]
Message-ID: <20071018192521.GC21136@shadowen.org> (raw)
In-Reply-To: <20071018111352.GA17039@elte.hu>
On Thu, Oct 18, 2007 at 01:13:52PM +0200, Ingo Molnar wrote:
>
> latest checkpatch.pl works really well on sched.c.
>
> there's only one problem left, this bogus false positive warning
> reappeared:
>
> WARNING: braces {} are not necessary for single statement blocks
> #5710: FILE: sched.c:5710:
> + if (parent->groups == parent->groups->next) {
> + pflags &= ~(SD_LOAD_BALANCE |
> + SD_BALANCE_NEWIDLE |
> + SD_BALANCE_FORK |
> + SD_BALANCE_EXEC |
> + SD_SHARE_CPUPOWER |
> + SD_SHARE_PKG_RESOURCES);
> + }
>
> (there's another place in sched.c that trips this up too.)
It actually never went away, some of the wronger reports went away such
as counting a commented statement as a single statement. The check for
length didn't make the cut for 0.11, as I was still thinking about
whether we wanted a subjective check on statements over and above the
"real" check for lines.
> i think it has been pointed out numerous times that it is perfectly fine
> to use curly braces for multi-line single-statement blocks. That
> includes simple cases like this too:
>
> if (x) {
> /* do y() */
> y();
> }
Yes and the comment in there actually counts as a statement for counting
statement purposes.
The plan is to move to counting lines and only winge on exactly one
line. I have half a mind to make a subjective check on statements and a
full check on lines. But probabally it will just move to lines.
> it's perfectly legitimate, in fact more robust. So if checkpatch.pl
> wants to make any noise about such constructs it should warn about the
> _lack_ of curly braces in every multi-line condition block _except_ the
> only safe single-line statement:
>
> if (x)
> y();
Indeed. We should probabally do more on the indentation checks in
general. The current direct check for:
if (foo);
bar();
Could probabally be generalised to look for this kind of error:
if (foo)
bar();
baz();
one();
-apw
next prev parent reply other threads:[~2007-10-18 19:25 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-12 19:26 [PATCH] checkpatch: Fix line number reporting Mike D. Day
2007-10-12 19:37 ` Andy Whitcroft
2007-10-13 18:35 ` Erez Zadok
2007-10-15 18:21 ` Andy Whitcroft
2007-10-16 17:59 ` Erez Zadok
2007-10-17 16:39 ` Andy Whitcroft
2007-10-18 11:13 ` latest checkpatch Ingo Molnar
2007-10-18 19:25 ` Andy Whitcroft [this message]
2007-10-18 19:39 ` Ingo Molnar
2007-10-18 20:02 ` Avi Kivity
2007-10-18 20:51 ` Ingo Molnar
2007-10-18 20:57 ` Jeff Garzik
2007-10-18 22:25 ` Randy Dunlap
2007-10-19 9:01 ` Andy Whitcroft
2007-10-18 23:16 ` Andi Kleen
2007-10-19 9:12 ` Ilpo Järvinen
2007-10-18 19:43 ` Andy Whitcroft
2007-10-18 20:00 ` Ingo Molnar
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=20071018192521.GC21136@shadowen.org \
--to=apw@shadowen.org \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/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.