Date: Thu, 07 Mar 2002 21:24:56 +0000 From: Mark Murray <mark@grondar.za> To: nate@yogotech.com (Nate Williams) Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/usr.bin/rwall rwall.c Message-ID: <200203072124.g27LOvRV092027@grimreaper.grondar.org> In-Reply-To: <15495.55333.300370.385829@caddis.yogotech.com> ; from Nate Williams <nate@yogotech.com> "Thu, 07 Mar 2002 14:14:13 MST." References: <15495.55333.300370.385829@caddis.yogotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > There is no clear direction in the above statement, although it has > > elements of truth from several disparate arguments. > > > > "Good reason" == "code rot". > > Code can not 'rot'. If it works, it works. All the rest of the > arguments are based on the invalid assumption. I disagree. If an API ir function changes, and a program does not have the information necessary to warn you of any problems that crop up, the code is said to have rotted. If you port code to a compiler or system that is different in some important way, and the compiler has not enough information to handle introduced incompatibilities, you have an analagous problem. If FreeBSD was to upgrade the C compiler (Gee, when are we ever going to do that?), things _will_ change. These things (if problematic in client code) are usually referred to as code rot if left unfixed or crudely patched over. 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?200203072124.g27LOvRV092027>