if bug in Ritchie C compiler - (nf)

[crl]

#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