From owner-cvs-all Thu Mar 7 13:58:26 2002 Delivered-To: cvs-all@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id AE80B37B405; Thu, 7 Mar 2002 13:58:17 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id g27LwFKD144742; Thu, 7 Mar 2002 16:58:15 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: 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> Date: Thu, 7 Mar 2002 16:58:14 -0500 To: nate@yogotech.com (Nate Williams), Mark Murray From: Garance A Drosihn Subject: Re: cvs commit: src/usr.bin/rwall rwall.c Cc: obrien@FreeBSD.org, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) 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 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