[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080224074730.GB31293@lazybastard.org>
Date: Sun, 24 Feb 2008 08:47:31 +0100
From: Jörn Engel <joern@...fs.org>
To: Krzysztof Halasa <khc@...waw.pl>
Cc: Al Viro <viro@...IV.linux.org.uk>,
David Newall <davidn@...idnewall.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Adrian Bunk <bunk@...nel.org>,
Roland Dreier <rdreier@...co.com>,
Glenn Streiff <gstreiff@...Effect.com>,
Faisal Latif <flatif@...Effect.com>,
linux-kernel@...r.kernel.org, general@...ts.openfabrics.org,
Andrew Morton <akpm@...ux-foundation.org>,
Greg Kroah-Hartman <greg@...ah.com>
Subject: Re: Merging of completely unreviewed drivers
On Fri, 22 February 2008 23:28:58 +0100, Krzysztof Halasa wrote:
> Al Viro <viro@...IV.linux.org.uk> writes:
>
> > IMO the line length overruns make good warnings. Not as in "here's a cheap
> > way to get more changesets", but as in "that code might have other problems
> > nearby" kind of heuristics.
>
> Sure, it does. However the human looking at the code is far better at
> spotting such problems. Machine-generated warnings are great when the
> machine is actually better than human.
I strongly disagree. Machine-generated warnings are a great way of
quickly locating a large amount of questionable code in an otherwise
overwhelming haystack. It doesn't even matter much, which warnings you
look for. Almost all code checkers find the same hotspots.
But there is a catch. If you have an over-eager warning police that
"fixes all the warnings", the warnings may be gone, but the very real
problems in near vicinity are not. Not to mention new problems
introduced by those claimed "fixes".
One fun hobby in my last job was to write a new code checker and locate
those problem areas hidden behind warning-free code. I had to write a
new checker so I would see below the polish of "fixes". The actual
problems found by the checker were often trivial and near-meaningless.
But those warnings are not the point at all, quite the contrary. The
only important thing was "that code might have other problems nearby".
Note one scary consequence: code checkers in the wrong hands are
actively harmful.
Jörn
--
One of my most productive days was throwing away 1000 lines of code.
-- Ken Thompson.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists