For statement not portable? (was: What does Z["ack"] = 5 mean?)

Leo de Wit leo at philmds.UUCP
Sat Oct 22 23:09:41 AEST 1988


In article <23 at auspex.UUCP> guy at 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.



More information about the Comp.lang.c mailing list