Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!bu.edu!orc!inews!cmdnfs!bhoughto
From: bhoughto@cmdnfs.intel.com (Blair P. Houghton)
Newsgroups: comp.lang.c
Subject: Re: Comparing strings...
Message-ID: <577@inews.intel.com>
Date: 23 Oct 90 16:22:53 GMT
References: <3330@idunno.Princeton.EDU> <11486@alice.att.com> <444@mole-end.UUCP>
Sender: news@inews.intel.com
Organization: Intel Corp, Chandler, AZ
Lines: 43

In article <444@mole-end.UUCP> mat@mole-end.UUCP (Mark A Terribile) writes:
Andrew Koenig (ark@europa.att.com) writes
>> > 	for (; *s && *s == *t; s++,t++);
>
>Note the semicolon on the  for(;;) .  Note that it's hard to note.
>
[Mark prefers]
>	while( . . . )
>		{}
>
>It's quite clear that this is an empty, no-effect statement.  It's a brace-
>thing where you expect a brace-thing, and it won't get missed on a faint
>printout the way a semicolon can be.

But Mark, I, and the Indian Hills cats, and cb(1)[*],
all expect our braces attached to our pants thusly:

	while (...) {
	}

which smells of something forgotten (or preempted).

Much more exact:

	while (...)
	    ;	/* empty */

You'll never, ever misconstrue that sucker as an error-in-editing.

				--Blair
				  "'Dave?  Dave?
				   Scratch lower, Dave...'
				   -if HAL9000 had won..."

[*] Actually, vanilla cb(1) will leave		while(){
						}

alone, while it'll split the braces in		while()
						    {}

and move them back under the initial:		while()
						{
						}