From owner-cvs-all Thu Mar 7 14:37:27 2002 Delivered-To: cvs-all@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 4E74E37B480; Thu, 7 Mar 2002 14:37:09 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id PAA29094; Thu, 7 Mar 2002 15:37:07 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g27Mb1402203; Thu, 7 Mar 2002 15:37:01 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15495.60301.617215.87829@caddis.yogotech.com> Date: Thu, 7 Mar 2002 15:37:01 -0700 To: Mark Murray Cc: nate@yogotech.com (Nate Williams), cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/usr.bin/rwall rwall.c In-Reply-To: <200203072227.g27MRWRV017994@grimreaper.grondar.org> References: <15495.59008.192220.654176@caddis.yogotech.com> <200203072227.g27MRWRV017994@grimreaper.grondar.org> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) 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 > > > 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. > > > > What problems (details)? Why it it hard to read? It is trivial to read > > and understand. > > Who says printf is not a macro? And if it is how would that cause problems above? > What is the return value? What does it matter if you ignore it? > void main() > { > printf("hello world\n"); > } > > Is much easier to read, making the one liner "hard". *phhfft* The first is so trivial that the second isn't any easier to read. > (Trivial example, > don't belabour this point). Ok, ignore the above sentence. > There is non-style(9) code in the tree that is much harder to read > before it is style.9-ified. And there is style(9) code in the the tree that is easier to read before it's style-ified as well. Your point? > > > NO! I am not. If I wanted to do that, I'd do something dumbass like > > > indent(1) all the code. > > > > It seems to me to be almost the same thing, but at least with indent, > > bugs are introduced. :( > > I guess you mean "NOT introduced"? *Duh* Look, I just introduced a bug in my email. :) > > *EVERYONE* likes well-written/safe code. Running it through lint and > > fixing errors doesn't necessarily provide you with either feature. > > Huh? > > Fixing errors doesn't help make safe(r) code? Bad wording. Fixing 'lint/gcc' complaints doesn't necessarily make the code safer or more well-written. The compiler and/or lint fixing may actually make the code harder to read, with no gain in safety. (Note, I said *may*, not *will not*.) Basically, I think having the changes reviewed before they are committed is the best solution. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message