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

[Blair P. Houghton]

In article <13009 at smoke.BRL.MIL> gwyn at smoke.BRL.MIL (Doug Gwyn) writes:
>In article <5915 at buengc.BU.EDU> bph at buengc.bu.edu (Blair P. Houghton) writes:
>-... Where the hell do you get the idea that I say that
>-ANSI X3.159-1989 says how to generate code?
>
>I bet he gets the idea from the same place I do: your own words!

Not the way they're written, he doesn't.

>-In article <3398 at auspex.auspex.com> guy at auspex.auspex.com (Guy Harris) writes:
>-Because in article <5879 at buengc.BU.EDU> I [bph] said, in my own words, precisely:

>Your use of "The standard states ... This means that now ..."
>conveys the implication that you think the subject was affected
>by the issuance of the standard.  Indeed, why bring this subject
>up at all in this newsgroup if you believed it has no relation
>to the standard?

I've already admitted I was wrong to think that K&R didn't
explicitly state what the standard states.  I admitted it
a week ago.  You forgot to include _that_ article, or maybe
you didn't forget.  In any case, that's not at issue, any
more.  What is at issue is the position that I said that
the standard requires code to be generated in any particular
way.  I never said it.  Don't say I did.  You can't show
I did.  I didn't.  Nope.  Never.

>-From: bph at buengc.BU.EDU (Blair P. Houghton)
>-Newsgroups: comp.std.c
>-Subject: Re: for(;;) vs. while(1) is a draw
>-Message-ID: <5879 at buengc.BU.EDU>
>-Date: 23 May 90 17:06:48 GMT
>-(I.e., and we can move this to alt.flame if you like,
>-despite the timelessness of your ego you're gonna die long
>-before C does, and not everyone needs to cling to "the old
>-ways."  The standard also remaindered `=-' forevermore; do
>-you want it back to provide compatibility with the "Hello,
>-world!!!!" program you wrote back in 1979?)
>-In article <12955 at smoke.BRL.MIL> gwyn at smoke.BRL.MIL (Doug Gwyn) writes:
>->Secondly, I don't know why you think the standard changes anything
>->whatsoever in the way that compilers must treat these constructs.
>->It doesn't.  They mean EXACTLY what they have always meant, and
>->EXACTLY the same code can be generated for them as before the standard.
>-"Can" is not "will," and "must" is not "may."
>-Before, an implementor that claimed their compiler did _no_
>-optimization could still turn `for(;;)' into an
>-unconditional branch, whereas `while(1)' was still forced
>-to compare-1-to-0-and-branch-if-not-equal.  ...
>-The obvious optimization
>-(possibly through a `-O' option) is to turn `while(1)' into
>-an unconditional branch, just like `for(;;)' was always.
>-Now, the standard has made it clear that without any
>-optimization BOTH constructs will become compare-and-
>-branch, and with or without optimization there has to be
>-some point where the compilation acts as if `for(;;)' had
>-been written `for(;1;)', which is to say (since the std is
>-explicit on this; ANSI X3.159-1989, Sec. 3.6.5.3, pp. 79,
>-ll. 31-39), as if it had been written `while(1)'.
*******************************************************************
>-"The semantic descriptions in this standard describe the behavior
>-of an abstract machine in which issues of optimization are irrelevant."
>-(ANSI X3.159-1989, Sec. 2.1.2.3, pp. 8, ll. 29-30)
*******************************************************************
>-An implementor that claimed to have a non-optimizing mode
>-on an ANSI-conforming compiler which then generated
>-different object code for the two constructs would be
>-committing fraud.  You can prove that and make it stick.
>
>In this one you were apparently claiming that there are
>different "old" and "new" ways,

Again, that's been settled.  The standard didn't say
anything that K&R didn't say.  That doesn't change my
contention that there are compilers that will have to be
fixed if they want to claim X3.159 conformance _and_ a lack
of optimization.  (We can still argue this if you like, but
it fits better in comp.misc under the subject-line "What is
optimization?")

>and you were continuing
>your argument that the standard will have some effect on
>this subject.  You stated explicitly that "the standard
>has made it clear that without any optimization ...",

That's the closest you've come to putting a foundation
under this entire misinterpretation, and I can see where
you might.  You're applying "made it clear" to "without any
optimization" and inferring that I'm saying "states how not
to optimize".  It's a wrong reading, in itself, and
tragically flawed in the face of the next development:

>which is of course wrong as the standard never mentions
>presence or absence of optimization, and in fact applies
>uniformly to all conforming implementations no matter
>what degree or kind of optimizations they apply.

Which is almost exactly what I and the standard say in the
three lines demarcated above by the asterisks, except for the
"never mentions" crack.  You think I dig out all those
reference numbers just because it's fun?  (It _is_ fun, but
it's not _just_ fun.) You think I'm capable of contradicting
myself within the space of a kilobyte and not seeing it?

Your opinion of me must be even lower than mine of you,
but at least I've got some basis for mine.

>-Path: smoke!adm!husc6!encore!bu.edu!buengc!bph
>-From: bph at buengc.BU.EDU (Blair P. Houghton)
>-Newsgroups: comp.std.c
>-Subject: Re: for(;;) vs. while(1) is a draw
>-Message-ID: <5897 at buengc.BU.EDU>
>-Date: 24 May 90 16:09:49 GMT
>-In article <12971 at smoke.BRL.MIL> gwyn at smoke.BRL.MIL (Doug Gwyn) writes:
>->This has nothing to do with for(;;) and while(1), which, AS I
>->SAID, have not changed one iota as the result of the standard.
>-Wrong.  Never before has anything at all been said about
>-adding '1' to the conditional expression in a
>-for-statement.  You're implying that X3J11 could well have
>-left that sentence entirely out of the standard.  For all
>-the difference it makes to *optimized* programs, it could
>-have; but a null expression is not a logical truism, so
>-they made it clear that a missing conditional is replaced
>-by 1 in this context.
>
>Here you flatly contradicted my assertion that the standard
>has changed nothing about the subject, and again you tried to
>express this in terms of optimization (i.e. code generation).

Two different things, and you've won the first.  There's a
bare lack of anything in the rationale on the replacement
of that '1'.  I noticed this, and it could have clued me
to the fact that there must have been prior art, if I'd
realized that prior art doesn't need rationale.

"For all the difference it makes to *optimized* programs"
is yet another direct statement making it clear that I
never thought the standard specified code generation.
I wasn't too ambiguous anywhere else, either.

				--Blair
				  "Except maybe down here."