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

Michael Friedman mfriedma at oracle.com
Sun May 27 06:25:00 AEST 1990


In article <5879 at buengc.BU.EDU> bph at buengc.bu.edu (Blair P. Houghton) writes:
>In article <12955 at smoke.BRL.MIL> gwyn at smoke.BRL.MIL (Doug Gwyn) writes:
>>In article <5876 at buengc.BU.EDU> bph at buengc.bu.edu (Blair P. Houghton) writes:
>>-This means that now, assuming that the compiler chooses 1 as
>>-the "nonzero constant,"
>>-	for (;;) statement
>>-and
>>-	while (1) statement

>>First of all, there are experienced C programmers (myself among them)
>>who do not think that "while(1)" is in ANY way preferable to "for(;;)".
>>People who learned Pascal before C seem to think so, though.

>It's more logical.  So sue me.  `for(;;)' is idiomatic
>and has to be explained, sometimes twice, to new programmers.

Perhaps, on the other hand I, at least, find it unesthetic - while(1)
implies a test.  I don't want to do a test.   I just want to do an
infinite loop.  for(;;) seems to imply that pretty well.

>(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?)

Note that =- was not widely used.  You'll find for(;;) in tons of
code.  One of the mandates fo the standards committee was to
standardize the language as it exists, not to modify it in order to
satisfy various people.  In particular, they were not supposed to
break existing code.

>>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.  (No, nobody
>cared, but one would have been right to write an SPR if one
>found out it wasn't the case.)  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.

No you can't.  I can just imagine you walking up to a compiler writer.

"You said that you don't optimize, but your compiler turns while(1)
into a compare and branch and for(;;) into a jmp.  That's fraud!!!"

"Huh?"

"You optimized when you said you wouldn't"

"So you got somehting for free.  File an enhancement request if this
matters to you."

"OK.  Enhancement request:  Please change your compiler so it
generates a compare and branch statement when it hits for(;;)"

Why do I think that that enhancement request wuld get a very low priority?


--
The passing of Marxism-Leninism first from China and then from the
Soviet Union will mean its death as a living ideology ... .  For while
there may be some isolated true believers left in places like Managua,
Pyongyang, or Cambridge, MA ...   - Francis Fukuyama



More information about the Comp.std.c mailing list