Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 7 Mar 2002 16:58:14 -0500
From:      Garance A Drosihn <drosih@rpi.edu>
To:        nate@yogotech.com (Nate Williams), Mark Murray <mark@grondar.za>
Cc:        obrien@FreeBSD.org, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/usr.bin/rwall rwall.c
Message-ID:  <p0510150db8ad8dd417dc@[128.113.24.47]>
In-Reply-To: <15495.55333.300370.385829@caddis.yogotech.com>
References:  <20020307120711.A62212@dragon.nuxi.com> <200203072038.g27KcGRV064577@grimreaper.grondar.org> <15495.55333.300370.385829@caddis.yogotech.com>

next in thread | previous in thread | raw e-mail | index | archive | help
At 2:14 PM -0700 3/7/02, Nate Williams wrote:
>Someone else wrote:
>  > 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.

Code effectively rots when the environment changes around it.
For instance, we are moving to a new gcc compiler, we're trying
to upgrade include files to the latest POSIX standards, and we
are also bringing FreeBSD up on three new hardware architectures
(little-endian vs big-endian, 32-bit vs 64-bit).  Experience
also (eventually) teaches us that coding practices like using
variables for the format string in printf's is just a bad
idea -- even if it's certainly "legal".

Compiler writers do not add warning messages just because they
want to encourage an obfuscated-C code contest.  They do it
because experience has shown that the code in question can be
a problem (ie, "bug") under some circumstances.

No one is advocating that we change working code into non-working
or unreadable code, but I do think there is a real benefit in
paying attention to these compiler warnings.  These changes, like
any other changes, should have some code review before being
committed -- but I think they are still good changes to work on.

I'll also agree that sometimes the correct fix is to fix the
compiler so it does NOT warn about code which is NOT really
a problem, in the cases where it is practical to change the
compiler (or the lint-type of tool).

Just MO...  :-)

-- 
Garance Alistair Drosehn            =   gad@eclipse.acs.rpi.edu
Senior Systems Programmer           or  gad@freebsd.org
Rensselaer Polytechnic Institute    or  drosih@rpi.edu

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?p0510150db8ad8dd417dc>