From owner-cvs-all@FreeBSD.ORG Sat Jul 26 14:35:03 2003 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 22C4337B401; Sat, 26 Jul 2003 14:35:03 -0700 (PDT) Received: from phk.freebsd.dk (phk.freebsd.dk [212.242.86.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1572243F3F; Sat, 26 Jul 2003 14:35:02 -0700 (PDT) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by phk.freebsd.dk (8.12.8/8.12.8) with ESMTP id h6QLYxV3011618; Sat, 26 Jul 2003 21:34:59 GMT (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.9/8.12.9) with ESMTP id h6QLYm5H056901; Sat, 26 Jul 2003 23:34:48 +0200 (CEST) (envelope-from phk@phk.freebsd.dk) To: Peter Jeremy From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 26 Jul 2003 07:21:42 +1000." <20030725212142.GB9176@cirb503493.alcatel.com.au> Date: Sat, 26 Jul 2003 23:34:48 +0200 Message-ID: <56900.1059255288@critter.freebsd.dk> cc: cvs-src@freebsd.org cc: src-committers@freebsd.org cc: cvs-all@freebsd.org Subject: Re: 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 X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2003 21:35:04 -0000 In message <20030725212142.GB9176@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. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@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.