for(;;) vs. while(1) is a draw

[Richard A. O'Keefe]

In article <5897 at buengc.BU.EDU>, bph at buengc.BU.EDU (Blair P. Houghton) writes:
> I just wanted to know
> whether _nobody_ was going to unobfuscate their coding
> style now that they know the dubious, increased efficiency
> of their `for(;;)' is now codified to be nil.

> I, for one, will encourage `while(1)' among new C
> programmers, because the increase in efficiency now comes
> from allowing maintainers to have a slightly lesser
> understanding of the history of C and still be able to
> understand this code.

Er, _what_ increase in efficiency?  I'm the kind of person who from time
to time takes the trouble to peek at the .s files produced by compilers
and see if they can be tweaked a bit.  I even figured out how to make a
compiler generate the 680x0 'DBRA' instruction once; highly non-obvious.
I've never yet been able to detect a significant difference between
for (;;) and while (1).

I loathe and detest while (1) because it's obfuscatory.
The thing is, a skilled programmer uses a while (..) statement because
that's the way it fell out of his preconditions, postconditions,
invariant, and so on.  You use 'while' to express "here after this
keyword is all the information you need about when the loop stops."
The only polite term I can think of for systematically violating this
conversational maxim is "non-Gricean".  As a sheerly practical matter,
it is virtually always a typo with extremely serious consequences if
the control expression in a while (...) or do while (...) is constant.
Having programming tools that warn about such blunders is _very_
useful.  And it would _not_ be a good idea to make them shut up about
the special cases while (1) and do while (1), that 1 could be the
result of a macro expansion.

For me, for (;;) loops are different.  They're what you write when you
have a loop that doesn't fall naturally into the while (..) pattern.
The character sequence (;;) has, I believe, no other use in C.  It's a
very clear signal "no, it _wasn't_ a mistake, I really _did_ mean to
put the real loop control somewhere else."

In fact, I would welcome a "lint" option that reported 'break' or
'continue' statements having a while (..) or do while (..) statement
as scope as being likely errors.  (Seriously!  If I were ever in a
position to recommend the purchase of one C checker or compiler over
another, having such an _option_ would influence my decision.)

> In a pinch, it will be one question
> *not* asked by someone coming from a Pascal background.

Um, I've recently had a lot more contact with people from a Pascal
background than I really wanted.  Quickly now, what's wrong with this:

	program main;
	    var i: integer;
	    procedure p(n: integer);
		begin
		    for i := 1 to n do write(' ');
		    writeln(i);
		end;
	    begin
		p(10);
	    end.

(I count three violations of the Pascal Standard.)  I've had people
from a Pascal background ask me "what's a pointer?"

> If, however, I were to write a conforming compiler and
> provide a no-optimization mode, both would compare 1 to 0
> before branching, because that's what the syntax implies.

But there is no way that a standard-conforming program can detect
whether there is a comparison there or not.

If one is going to engage in such micro-exegesis, one might pay careful
attention to the fact that the quoted section standard does _not_ say
that for (x;;y) is equivalent to for (x;1;y) but to for (x;c;y) for
*some* non-zero integer constant.  Is there anything to stop a
conforming C compiler from behaving as if the constant were 137, and
"optimising" both for (;;) and while (137), but not while (1)?
If so, what exactly?

> 				  "Have you ever even heard of
> 				   'the law of least surprise?'"

I have, but when I see people write while (1), I really wonder about _them_...

-- 
"A 7th class of programs, correct in every way, is believed to exist by a
few computer scientists.  However, no example could be found to include here."