Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!killer!convex!uunet!mcvax!hp4nl!philmds!leo
From: leo@philmds.UUCP (Leo de Wit)
Newsgroups: comp.lang.c
Subject: Re: For statement not portable? (was: What does Z["ack"] = 5 mean?)
Message-ID: <841@philmds.UUCP>
Date: 22 Oct 88 13:09:41 GMT
References: <14999@agate.BERKELEY.EDU> <4700019@m.cs.uiuc.edu> <6945@cdis-1.uucp> <837@philmds.UUCP> <23@auspex.UUCP>
Reply-To: leo@philmds.UUCP (Leo de Wit)
Organization: Philips I&E DTS Eindhoven
Lines: 53

In article <23@auspex.UUCP> guy@auspex.UUCP (Guy Harris) writes:
|>|It is also possible that compiler writers will get the "for" loop
|>|handling wrong.  It is unwise to depend on "for" loops in portable
|>|code.  Use a "while" loop instead.
    [my lines deleted]...
|Gee, I thought the comment about the "for" loop was rhetorical, inserted
|only to indicate that if you decide to avoid using legal C constructs
|(and subscripting an integer by an array most definitely *is* legal)
|because some implementor might get them wrong, there's no clear place to
|stop - hey, if they don't treat "a[b]" as "*(a + b)" as they're supposed
|to, they might get "for" wrong, and then they might even get "while"
|wrong too.  I didn't think it was referring to some known problem. 

I didn't interprete the comments about forbidding to subscript an
integer by an array as 'some implementor might get them wrong'; I
thought they were referring to plain errors in the compiler (read: the
compiler writer already was wrong about something that's a legal C
construct).  Although I like K&R as it is, it is not unthinkable that
compiler writers might get things wrong. Since I thought Dr. Andrews
was referring to just a plain error in respect to the subscripting (not
a 'we shall fix this so it will not be used', which of course is an
error too), I thought he was too when referring to "for" loops (well,
maybe he DID know some problem in some compiler that I had not yet
encountered). Most people will agree when I say that we should avoid
these compilers, if possible.

As an aside:
In K&R, page 56, section 3.5:
/* start quotation */

   The for statement

       for (expr1; expr2; expr3)
            statement

is equivalent to

       expr1;
       while (expr2) {
            statement
            expr3;
       }
/* end quotation */

If compiler writers would unconditionally rewrite "for" loops to
"while" loops in this manner, they would get it wrong (try stuffing a
"continue" statement in the 'body' statement; in the "for" case expr3
must be evaluated, in the "while" case not). Of course careful reading
of K&R reveals that "continue" is a special case, but careful reading
should also prevent from getting the indexing stuff wrong. It seems
that careful reading of K&R is still the hard one...

           Leo.