leo@philmds.UUCP (Leo de Wit) (10/18/88)
In article <6945@cdis-1.uucp> tanner@cdis-1.uucp (Dr. T. Andrews) 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. The semantics of the "for" statement seem pretty clear, though (see K&R Appendix A, 9.6 & 9.8, 9.9). Could you be a bit more specific about how they get it wrong? I didn't see any compilers broken in this respect yet. If there are any, they would break a lot of existing code. And then, what standards are we going to support? Those imposed by generally accepted documents, or those thrusted upon you by faulty compilers? If it's going to be the latter, you must already be very sure about how well each and every compiler generates code for each and every C construct. Apart from the fact that this seems hardly doable, one wonders now what other constructs are potentially hazardous... And I liked the for statement so well (and I'm not yet convinced). Leo. for ( t; r; a) n;
friedl@vsi.COM (Stephen J. Friedl) (10/19/88)
In article <6945@cdis-1.uucp> tanner@cdis-1.uucp (Dr. T. Andrews) 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. In article <837@philmds.UUCP>, leo@philmds.UUCP (Leo de Wit) writes: > The semantics of the "for" statement seem pretty clear, though (see > K&R Appendix A, 9.6 & 9.8, 9.9). Could you be a bit more specific about > how they get it wrong? I didn't see any compilers broken in this respect > yet. If there are any, they would break a lot of existing code. Hold it hold it everybody. The only thing wrong with Dr. Andrews' note is the lack of the :-). The posting to which he was responding claimed that since some compilers can't hack "int[ptr]" array indexing that it should be considered nonportable. Well, int[ptr] is well-defined in the C language, and if a compiler doesn't support it then the compiler is broken. Dr. Andrews is making this point with sarcasm. -- Steve Friedl V-Systems, Inc. +1 714 545 6442 3B2-kind-of-guy friedl@vsi.com {backbones}!vsi.com!friedl attmail!vsi!friedl ---------Nancy Reagan on the Three Stooges: "Just say Moe"---------
guy@auspex.UUCP (Guy Harris) (10/19/88)
>|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. > >The semantics of the "for" statement seem pretty clear, though (see >K&R Appendix A, 9.6 & 9.8, 9.9). Could you be a bit more specific about >how they get it wrong? I didn't see any compilers broken in this respect >yet. If there are any, they would break a lot of existing code. 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.
sbc@sp7040.UUCP (Stephen Carroll) (10/21/88)
In article <888@vsi.COM>, friedl@vsi.COM (Stephen J. Friedl) writes: ] In article <6945@cdis-1.uucp> tanner@cdis-1.uucp (Dr. T. Andrews) 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. ] ] In article <837@philmds.UUCP>, leo@philmds.UUCP (Leo de Wit) writes: ] > The semantics of the "for" statement seem pretty clear, though (see ] > K&R Appendix A, 9.6 & 9.8, 9.9). Could you be a bit more specific about ] > how they get it wrong? I didn't see any compilers broken in this respect ] > yet. If there are any, they would break a lot of existing code. ] ] Hold it hold it everybody. The only thing wrong with Dr. ] Andrews' note is the lack of the :-). ] ] The posting to which he was responding claimed that since some ] compilers can't hack "int[ptr]" array indexing that it should be ] considered nonportable. Well, int[ptr] is well-defined in the C ] language, and if a compiler doesn't support it then the compiler ] is broken. Dr. Andrews is making this point with sarcasm. ] you know, i just went back a re-read Dr. Andrews posting and he was being sarcastic. the first time through, i thought, as most everyone else did, that he was serious. i personally feel that he should be beat about the head and shoulders with a wet fish for not including a ":-)" in his posting though. ;-]
leo@philmds.UUCP (Leo de Wit) (10/22/88)
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.