From owner-cvs-all Thu Mar 7 14:11:12 2002 Delivered-To: cvs-all@freebsd.org Received: from storm.FreeBSD.org.uk (storm.FreeBSD.org.uk [194.242.139.170]) by hub.freebsd.org (Postfix) with ESMTP id 4FAFC37B402; Thu, 7 Mar 2002 14:10:59 -0800 (PST) Received: (from uucp@localhost) by storm.FreeBSD.org.uk (8.11.6/8.11.6) with UUCP id g27MAtm62452; Thu, 7 Mar 2002 22:10:55 GMT (envelope-from mark@grimreaper.grondar.za) Received: from grimreaper (localhost [127.0.0.1]) by grimreaper.grondar.org (8.12.2/8.12.2) with ESMTP id g27M5MRV015704; Thu, 7 Mar 2002 22:05:22 GMT (envelope-from mark@grimreaper.grondar.za) Message-Id: <200203072205.g27M5MRV015704@grimreaper.grondar.org> 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 References: <15495.56353.158608.817241@caddis.yogotech.com> In-Reply-To: <15495.56353.158608.817241@caddis.yogotech.com> ; from Nate Williams "Thu, 07 Mar 2002 14:31:13 MST." Date: Thu, 07 Mar 2002 22:05:22 +0000 From: Mark Murray Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > 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. > > Then the code has changed. It has not rotted. That means whomever > changed the code has not done a good job. Maybe; but this is a job that is so close to impossible that it is effectively so. Example: recently, some structure elements in were changed from u_int to gid_t, likewise some group-related function parameter types. Consistent code style in this case made it easy to look for and check. I'm looking at some much older Sun code; many functions are prototyped as extern foo(); even though they have a perfectly good prototype in some system header. Ordinarily, fixing the header when a function is updated fixes a problem; not in this case. Such programs break unpredictably. > > 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. > > Then you have a compiler problem, not a code problem. > > Neither of the above problems are in effect with your recent lint > changes. Wrong. To declare so is to admit you haven't read the diffs. > > 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. > > See above. The code you are fixing has not changed, and the compiler > still produces correct code. void main(){printf("hello world\n");} also produces correct code and runs, but creates problems during compiler and library upgrades. It his hard to read, and is unpredictable in silly ways. > You're changing things for the sake of change, and unfortunately NO! I am not. If I wanted to do that, I'd do something dumbass like indent(1) all the code. > introducing both signficant and insignificant bugs in the process. Even > worse, the readability of the original code is *lessened* because you're > modifying to make automatic tools happy with, rather than the *much* > more important (IMO) job of making the code reabable for a person who > needs to modify the code at a later point. I disagree, although I concede that you may find the changes less readable, I find them more so. I am also attempting to stay within the spirit of style(9). I object to obfuscated C (although the IOCCC is fun), and I think that code should be well-written and _safe_. > IMO, the *single* biggest positive to OpenSource programs is the ability > to see what's going on. That's what drew me to it 15 years ago, and it > seems that people are now spending more time making tools happy, rather > than worrying about Real (tm) bugs. I am proactively hunting bugs. I am using tools so I can get more of them, and I am getting rid of cruft so that the tools do their job properly. I am not perfect, and I make mistakes like anyone else. If I introduce a bug, I'll take resonsibility for it. My intention is to fix more bugs (or help expose them) than I create. > (And, for what it's worth, this sort of things happens at work, and I > hate it just as much there as I do here...) Sure. Lets just not get too stuck on the "no changes, OK?" route. As I said in another mail, I'm negotiable. 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