Date: Sun, 27 Jul 2003 15:44:03 +0200 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Alexander Leidinger <Alexander@Leidinger.net>, cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org, dds@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 Message-ID: <63496.1059313443@critter.freebsd.dk> In-Reply-To: Your message of "Sun, 27 Jul 2003 09:26:52 EDT." <Pine.NEB.3.96L.1030727091934.49952A-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <Pine.NEB.3.96L.1030727091934.49952A-100000@fledge.watson.org>, Robe rt Watson writes: >I can't help wondering if the single most positive step in the direction >of having formalism and analysis tools available in development wouldn't >be to use a language other than C... :-) There are certainly areas where C could be improved to fit the task of modern and portable systems programming better, but all things considered I only think that would result in rather marginal prevention of certain "brain-o" style bugs and less rules in style(9) to enforce. I am on the other hand pretty sure that the biggest improvement would not come from changing the language in which we write our code as much as from programs which read that code, and answer the questions which it would otherwise be very time consuming to get a reply to. For instance, since one can manually establish the answer to the question "how is this line of code reached", producing more or less kernel backtraces that lead to the line in questions, I can't see why we shouldn't be able to automate that task. -- 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?63496.1059313443>