rgenter@j.bbn.com (Rick Genter) (01/15/87)
> The > other example with the *cp++'s was subtle and at worst confusing. Not only that, but it was outright wrong. Since the only guarantee on ++ is that it will be evaluated before the start of the next statement, the compiler is free to implement the expression as: if ( (booltemp = *cp | *cp | *cp, cp += 3, booltemp) ) { ... } or, alternatively, if ( (cp += 3, *cp | *cp | *cp) ) { ... } or any other combination or permutation of increment and dereference. The only way to be safe is to never have the same object undergo two side effects in the same statement/expression. - Rick -------- Rick Genter BBN Laboratories Inc. (617) 497-3848 10 Moulton St. 6/512 rgenter@bbn.COM (Internet new) Cambridge, MA 02238 rgenter@bbnj.ARPA (Internet old) seismo!bbn.com!rgenter (UUCP)
greg@utcsri.UUCP (Gregory Smith) (01/16/87)
In article <2356@brl-adm.ARPA> rgenter@j.bbn.com (Rick Genter) writes: >Not only that, but it was outright wrong. Since the only guarantee on ++ >is that it will be evaluated before the start of the next statement, the >compiler is free to implement the expression as: > > if ( (booltemp = *cp | *cp | *cp, cp += 3, booltemp) ) { > ... > } > True; >or, alternatively, > > if ( (cp += 3, *cp | *cp | *cp) ) { > ... > } > False. At least one of the *cp's will reference one of cp[0],cp[1],cp[2] (using the original value of cp), since the post-increment was used. The following might be generated: if ( (cp += 3, cp[-1] | cp[-1] | cp[-1]) ) { which references cp[2] three times. In fact it seems to me that any legal ordering of *cp++|*cp++|*cp++ will generate references to old_cp[0], old_cp[1] and old_cp[2] only, but I won't try to prove it. Our Ns32k compiler often does "*p++" as "++p, p[-1]", and it is conceivable that three ++cp could be folded into cp += 3 as above. -- ---------------------------------------------------------------------- Greg Smith University of Toronto UUCP: ..utzoo!utcsri!greg Have vAX, will hack...