Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 07 Mar 2002 22:27:32 +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:  <200203072227.g27MRWRV017994@grimreaper.grondar.org>
In-Reply-To: <15495.59008.192220.654176@caddis.yogotech.com> ; from Nate Williams <nate@yogotech.com>  "Thu, 07 Mar 2002 15:15:28 MST."
References:  <15495.59008.192220.654176@caddis.yogotech.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
> > 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?
What is the return value?

void main()
{
	printf("hello world\n");
}

Is much easier to read, making the one liner "hard". (Trivial example,
don't belabour this point). There is non-style(9) code in the tree that
is much harder to read before it is style.9-ified.

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

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

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?200203072227.g27MRWRV017994>