Date: Thu, 07 Mar 2002 22:05:22 +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: <200203072205.g27M5MRV015704@grimreaper.grondar.org> In-Reply-To: <15495.56353.158608.817241@caddis.yogotech.com> ; from Nate Williams <nate@yogotech.com> "Thu, 07 Mar 2002 14:31:13 MST." References: <15495.56353.158608.817241@caddis.yogotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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 <grp.h> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200203072205.g27M5MRV015704>