🚀 go-pugleaf

In article <3381@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes:
>>It's more logical.
>
>Some agree, some don't.  Who cares?  *I* certainly don't; I'll continue
>to use "for (;;)", because I'm used to it.

Good for you.  I probably will, too.  I just won't explain
it as anything other than a curiosity.

>>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.
>
>And somebody could then throw K&R at them, since the "for(...;...;...)
>is equivalent to <while construct>" stuff was in there, too.

Ayup.  They'd be optimizing without being asked to, but then,
they'd say "so what's K&R?  We wrote ours by altering Whitesmith's.".

>>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.
>
>With a bald statement like "you can prove that and make it stick", I'd
>almost be tempted to call your bluff and start selling a version of,
>say, GCC that *does* generate stupid code for "while(1)" while claiming
>it's ANSI-compliant, and watch you *try* to prove it.

It requires a stricter definition of "non-optimizing" than
it seems most people carry around with them.  They certainly
don't see it the way I do.

And I don't believe a word GNU says.  Nope.  Not one.

>Much though you may not like it, and much though you may think
>otherwise, the ANSI C standard just says how a C implementation (which
>might not generate code at all - consider an interpretive implementation
>that, stupid though it may seem, scans source and interprets it on the
>fly, without even generating some internal code); it does *not* dictate
>whether it generates the "best" code for some construct, nor even
>whether it generates the *same* code for equivalent constructs - as
>shown by, well, err, umm,

Here we go:

	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.
I'd expect a compiler with no heuristics in it to prove me right.

Add optimization, and make it good, and it all becomes

	label: statement goto label;

>>"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)
>
>to quote an earlier disputant here.

Looks familiar.  Like Flaubert.

I didn't say the standard specified optimization.  I said the
implementor did, or rather, the implementor specified a _lack_
of it.  Then it went and optimized.

				--Blair
				  "I wanna clean bout.  No butting,
				   biting, or rabbit punching.  Best
				   two out of three hypothetical
				   situations wins.  Now go back
				   to your corners and come out
				   coding."