From: Andy Whitcroft <apw@shadowen.org>
To: Pekka Enberg <penberg@cs.helsinki.fi>
Cc: Ingo Molnar <mingo@elte.hu>,
Andrew Morton <akpm@linux-foundation.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 15:02:43 +0100 [thread overview]
Message-ID: <20070928140243.GO18163@shadowen.org> (raw)
In-Reply-To: <84144f020709280637w2290aec5gf3e8f90b08f53cc8@mail.gmail.com>
On Fri, Sep 28, 2007 at 04:37:49PM +0300, Pekka Enberg wrote:
> Hi Andy,
>
> On 9/28/07, Andy Whitcroft <apw@shadowen.org> wrote:
> > That is unfair. Every time we discuss it I state that I disagree that
> > hiding mostly useful tests is a good thing. I would love the tests to
> > be 100% accurate, but if I removed all the tests that can false positive
> > I would literally have none. There is a balance to be struck and we
> > have significantly different ideas on where the balance is.
>
> Are you disagreeing with the numbers Ingo posted? 25,000 false
> positives for the kernel is beyond silly... Existing conventions
> should matter a lot and the default configuration for a static code
> checker should really be 100%. So why not hide the potentially useful
> warnings under -Wtoo-strict or similar command line option?
I have not run across the whole kernel to find out, his estimation is
likely high as his sample (mm/sched.c) includes a particular construct
(multiple assignment) which is reported and overly common in that
piece of code. If I take mm/signal.c (also big) I get 1/1000 files,
and those two are easily fixed. I should note it shows some 62 actual
real violations in that file.
I do receive automated checks of every patch posted to lkml and I work
to remove the false positives from them. The false positive ratio is
very low in those reports and it those which drive my development effort.
checkpatch is a work in progress and likely will be for many years to
come.
I have propose we 'gate' those subjective tests, and have asked for
input on that thread on the default for those tests.
-apw
next prev parent reply other threads:[~2007-09-28 14:03 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 [this message]
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
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=20070928140243.GO18163@shadowen.org \
--to=apw@shadowen.org \
--cc=akpm@linux-foundation.org \
--cc=jschopp@austin.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=penberg@cs.helsinki.fi \
--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