From: utzoo!decvax!harpo!eagle!wb2!houxz!ihnp4!ixn5c!inuxc!pur-ee!CSvax:Pucc-H:Physics:crl Newsgroups: net.lang.c Title: Re: re: if bug in Ritchie C compiler - (nf) Article-I.D.: pur-phy.662 Posted: Sat Jan 29 16:01:14 1983 Received: Mon Jan 31 04:26:12 1983 #R:burl:-5400:pur-phy:15700006:000:1755 pur-phy!crl Jan 29 14:35:00 1983 In bringing this case up originally, I didn't see that the way the Ritchie compiler optimized the evaluation of the if expression out would make much of a difference in any *sane* code. However, in thinking about it some more, I believe that there is a possibility that this may come up in some software somewhere. Suppose one was writing a program that was to be distributed, and for this reason, you include 2 tunable parameters A and B that are #define's. It would then not seem like a potential disaster to say: if (i++ * (A-B) > 20) { /* is i incremented? */ . . . would it? Who would expect that if A==B, the i++ would never be executed at all? In fact, since I postulated that this code is distributed, the bug might be just about impossible to track down. In my case, I was just lucky because it wasn't A-B but a hard-coded '0'. Sure programmers are warned about counting on side-effects, but we all use them when there doesn't seem to be a problem. The above would work on pcc, but also on R's cc, except at an installation who set A=B. Furthermore, nary a message is printed by either the compiler or lint about the non-evaluation of the "if" test or the unreachability of the "then" portion. So the question remains: is it a bug, or not? While it is true that expressions may be re-ordered, I agree with yale-comix!leichter that the compiler should not be allowed to *avoid* the evaluation of a non-constant expression. If A and B above were variables and not constants, I definitely would not want a compiler to evaluate (A-B), decide it was == 0, and not perform the i++. While it is very clear here that that would be a bug, the two cases are analogous, at least to me. Charles LaBrec pur-ee!Physics:crl purdue!Physics:crl