🚀 go-pugleaf

In article <5915@buengc.BU.EDU> bph@buengc.bu.edu (Blair P. Houghton) writes:
-In article <3398@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes:
-Because in article <5879@buengc.BU.EDU> I [bph] said, in my own words, precisely:
->>	for(;;) statement
->>	while(1) statement
->>	label: statement if(1) goto label;
->>are all the same; exactly the same, when translated into object code
->>without thinking about it.  You could contend that the third is
->>my invention, but the standard says the first two are identical.
->The standard does *NOT* say, in any way, shape, or form, that they are
->"exactly the same, when translated into object code without thinking
->about it".
-... 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!

-From: bph@buengc.BU.EDU (Blair P. Houghton)
-Newsgroups: comp.std.c
-Subject: for(;;) vs. while(1) is a draw
-Message-ID: <5876@buengc.BU.EDU>
-Date: 22 May 90 20:52:33 GMT
-The standard states (Sec. 3.6.5.3, pp. 80) that omitting the
-first or third expressions in `for( e1; e2; e3 )' replaces
-them with void expressions, but that if the second is omitted
-it's "replaced by a nonzero constant."
-This means that now, assuming that the compiler chooses 1 as
-the "nonzero constant,"
-	for (;;) statement
-and
-	while (1) statement
-are identical _in_every_way_ and there's no reason for
-a programmer to expect more-optimal behavior from the
-former (it's an old argument that the slight obfuscation
-of the empty-for is balanced by a greater probability that
-the compiler will make faster, smaller object-code from it).

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?

-From: bph@buengc.BU.EDU (Blair P. Houghton)
-Newsgroups: comp.std.c
-Subject: Re: for(;;) vs. while(1) is a draw
-Message-ID: <5879@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@smoke.BRL.MIL> gwyn@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, 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 ...",
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.

-Path: smoke!adm!husc6!encore!bu.edu!buengc!bph
-From: bph@buengc.BU.EDU (Blair P. Houghton)
-Newsgroups: comp.std.c
-Subject: Re: for(;;) vs. while(1) is a draw
-Message-ID: <5897@buengc.BU.EDU>
-Date: 24 May 90 16:09:49 GMT
-In article <12971@smoke.BRL.MIL> gwyn@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).