Date: Thu, 07 Mar 2002 20:38:16 +0000 From: Mark Murray <mark@grondar.za> To: obrien@FreeBSD.ORG Cc: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/usr.bin/rwall rwall.c Message-ID: <200203072038.g27KcGRV064577@grimreaper.grondar.org> In-Reply-To: <20020307120711.A62212@dragon.nuxi.com> ; from "David O'Brien" <obrien@FreeBSD.ORG> "Thu, 07 Mar 2002 12:07:11 PST." References: <20020307120711.A62212@dragon.nuxi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Thu, Mar 07, 2002 at 01:28:24PM +0000, Mark Murray wrote:
> > > This is by *NO* means more readable than the old code!
> >
> > I guess this comes down to an opinion, right? :-)
>
> There seems to be more NO's than agreements with you in this case. BUT
> that does not matter. We've operated under the "don't change things w/o
> a good reason" to (1) settle cases of opinion like this. And (2) because
> changing things too much throws away over a decade of tested proven code.
> This is something that should not be taken lightly. We hold our age up
> all the time as one of our advantages over Linux. However these
> WARNS/lint runs are making our code as volatile as the GNU stuff we snub.
There is no clear direction in the above statement, although it has
elements of truth from several disparate arguments.
"Good reason" == "code rot". Look at a lot of our Sun-derived code,
the RPC stuff. Very ropey WRT to "pointer == int" cruft, incompatible
(but harmless because unused) functions/declarations/usages. Etc.
That is an extreme example.
"Old code" != "Good code". Compiler technology changes. Programming
style changes. IE, before the Morris worm and quite a bit after it,
no-one cared about buffer overflows.
It is scarecly possible today to make a commit without some kind
of style-related comeback (I'm not surprised; just about any file
in sys/kern/ is internally inconsistent with itself).
I see two ways to fix this; 1) when you notice problems 2) proactively.
I am choosing proactively.
I'd like to get the code base to the point where lint(1) shows
things that are genuinely ropey, with 2 kinds of warnings not
cropping up: 1) stupid ones which we tell lint(1) to not tell us,
and 2) stupid programmer crap that lint warned us about and we
fixed.
NOW:
I'll slow down if you want.
I'll post lint warnings if you want.
I'll put up an explanation of what I'm doing
if folks think that may help.
I want to co-operate, and I don't like conflicts,
so I can adapt.
BUT:
I _do_ want us to be fixing old crappy code to something
slightly closer to 20th-century practice. Proactively, not by
accident.
M
--
o Mark Murray
\_
O.\_ Warning: this .sig is umop ap!sdn
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200203072038.g27KcGRV064577>