cvs commit: src/sys/kern init_main.c kern_malloc.c md5c.c subr_autoconf.c subr_mbuf.c subr_prf.c tty_subr.c vfs_cluster.c vfs_subr.c

[Poul-Henning Kamp]

In message <20030725212142.GB9176 at cirb503493.alcatel.com.au>, Peter Jeremy writ
es:
>On Wed, Jul 23, 2003 at 01:28:24AM +0200, Poul-Henning Kamp wrote:
>>Please remember that the problem at hand is getting -Werror back
>>on the kernel so we can catch issues like the warning in umtx.
>
>Why is -Werror such a holy grail?

I think I can say without doubt that next to Bruce, I have been
trawling more code in the FreeBSD kernel than anybody and consequently
seem more bogus code and "neat hacks" than I care for.

When I first started to interest myself with the mechanics of
sanitizing the kernel source, it was because two common symbols had
the same name, which gave rather non-newtonian behaviour under a
given set of circumstances which I ran into rather often.

Subsequently, I have written a couple of minor scripts to try to
help make sure certain kinds of consistency remains in force in the
kernel (this was the genesis of src/tools btw).

I have even gone as far as to spend a fair bit of time testing
various code analysis tools, a decade ago I used Purify, these days
FlexeLint is my favourite, on the kernel correctling as I go the
most severe problems I found that way.

Considering that we pride our selves of having the "most experienced"
source code in the industry, and generally belive that we are better
than the rest, the sort of bugs I have found and corrected have amazed
me, most so the long list of programs nailed by phkmalloc.

And on a more abstract level it is a sobering thought in that light,
that the way we write code is essentially unchanged since the time
when the guy who taught me to program, was taught it, by some of
the people who helped write the first ALGOL-60 compiler.

We still have no tools which help us translate high level abstractions
into low level code or for that matter to validate the high level
abstractions in the first place.

Number people have gone from pencil and paper to spreadsheets,
writes from type writers to word processing, graphic artists from
brush and pen to illustrator and photoshop.

But programmers, they still go directly from brainwave to source
code with no technology assistance.  I am sure that most languages
have expressions about the state of cobblers kids footwear and what
bakers kids eat, and they apply to programmers as much as that.

If we could even just claim that people have gotten better at it
but we have not attained a reduction in bugs per line of code over
the last 40 years that anybody has been able to measure.

(And no, don't point to another language which is much better for
writing operating system kernels, it would be a waste of your time.)


Given all that, I firmly belive we should embrace every little bit
of help we can get from tools and programs we have, even if that
means minor inconveniences and a certain cramping of style here and
there.

The role of the source code we write is to express clearly and
efficiently our intention for the compiler to interpret into
executable code, and failing that, to make it clear what the intent
is, so that a future improved compiler can get the chance.

For every dubious construct in that source code the compiler can
warns us about, we will have a certain fraction of actual bugs less.

Provided, of course, that people actually read the warnings.

And that is why -Werror is not a holy grail, but a damn efficient
means forcing the bastards to read the warnings.

I will readily agree that GCC is far from optimal in many ways, and
the particular way used to control which detected conditions are
fatal, which are warnings and which are ignored is very deficient.

But it is the best we have, and it is better than having nothing.

And should anybody take a liking to the idea of improving GCCs
suitability to our coding standards and ideals, I am sure he would
find people like Peter, Bruce and me very grateful.

Another project in the same category would be a source-code locking
analyzer ie: read the source code, check that locks are locked/unlocked
in the right order, the right number of times etc etc etc.  Pretty
much what WITNESS does at runtime, but done at compile time and
covering the entire source code including all the exceptions, rather
than only the beaten path which WITNESS sees.

</SOAPBOX>

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.