From: Andy Whitcroft <apw@shadowen.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: Andrew Morton <akpm@osdl.org>,
Randy Dunlap <rdunlap@xenotime.net>,
Joel Schopp <jschopp@austin.ibm.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] update checkpatch.pl to version 0.10
Date: Fri, 28 Sep 2007 10:52:07 +0100 [thread overview]
Message-ID: <20070928095207.GA18163@shadowen.org> (raw)
In-Reply-To: <20070928084003.GA18882@elte.hu>
On Fri, Sep 28, 2007 at 10:40:03AM +0200, Ingo Molnar wrote:
>
> * Andy Whitcroft <apw@shadowen.org> wrote:
>
> > This version brings a number of new checks, and a number of bug fixes.
>
> your checkpatch patch itself produces 22 warnings ...
>
> i ran it over kernel/sched.c and there are many bogus warnings that i
> reported to you earlier:
>
> WARNING: multiple assignments should be avoided
> #2319:
> + max_load = this_load = total_load = total_pwr = 0;
>
> and new bogus ones:
>
> ERROR: need consistent spacing around '*' (ctx:WxV)
> #5287:
> + mode_t mode, proc_handler *proc_handler)
>
> ERROR: need consistent spacing around '*' (ctx:WxV)
> #5328:
> +static ctl_table *sd_alloc_ctl_cpu_table(int cpu)
>
> ERROR: need space before that '*' (ctx:VxV)
> #209:
> +# define INIT_TASK_GRP_LOAD 2*NICE_0_LOAD
>
> why did you ignore my feedback? Ever since v8 the quality of
> checkpatch.pl has been getting worse and worse as there are way too many
> false positives. I'm still stuck on v8 for my own use, v9 and v10 is
> unusable.
I think if you read your incoming email you will see nothing of the sort.
I have discussed this with you and in public. The multiple assignment
check you dissagree with and we have softened it in direct response to that
dislike. However, the main proponent of this existing wanted that check.
Therefore it has stayed. The other false positives you report are real.
Some are fixed in my development version, others are not. They come
from the fact that I was asked for better checks on '*' and the like in
its binary mode. To get that I had to actually start telling unary and
binary uses of the same operator appart. That is hard in the face of
typedef'd types. I am working to make it better.
However, the key here is that it will never be 100%, not without
becoming a try C parser. The output is a _guide_ if you don't like its
output ignore the reports you dislike. I for one send out patches with
style violations where I deem that the code is better that way.
-apw
prev parent reply other threads:[~2007-09-28 9:52 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-12 15:00 [PATCH] update checkpatch.pl to version 0.10 Andy Whitcroft
2007-09-28 8:40 ` Ingo Molnar
2007-09-28 9:01 ` Andrew Morton
2007-09-28 9:22 ` Andy Whitcroft
2007-09-28 9:39 ` Ingo Molnar
2007-09-28 10:00 ` Andy Whitcroft
2007-09-28 10:46 ` Christian Borntraeger
2007-09-28 11:03 ` WANG Cong
2007-09-28 14:19 ` Jan Engelhardt
2007-09-28 16:57 ` Randy Dunlap
2007-09-28 10:49 ` Ingo Molnar
2007-09-28 13:21 ` Andy Whitcroft
2007-09-28 13:37 ` Pekka Enberg
2007-09-28 14:02 ` Andy Whitcroft
2007-09-28 15:50 ` Joel Schopp
2007-09-28 17:26 ` Randy Dunlap
2007-09-28 17:46 ` Andrew Morton
2007-09-29 9:22 ` Andy Whitcroft
2007-10-05 5:56 ` Ingo Molnar
2007-09-28 16:51 ` Sam Ravnborg
2007-09-28 9:44 ` Ingo Molnar
2007-09-28 9:52 ` Andy Whitcroft [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=20070928095207.GA18163@shadowen.org \
--to=apw@shadowen.org \
--cc=akpm@osdl.org \
--cc=jschopp@austin.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rdunlap@xenotime.net \
/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