Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!van-bc!ubc-cs!uw-beaver!uw-entropy!dataio!bright
From: bright@Data-IO.COM (Walter Bright)
Newsgroups: comp.lang.c
Subject: Re: Is this a bug in Turbo C 2.0?
Message-ID: <2374@dataio.Data-IO.COM>
Date: 12 Mar 90 19:57:04 GMT
References: <3210@pur-phy> <60@datcon.UUCP> <E24hr$1@cs.psu.edu> <29446@amdcad.AMD.COM>
Reply-To: bright@Data-IO.COM (Walter Bright)
Organization: Data I/O Corporation; Redmond, WA
Lines: 28

In article <29446@amdcad.AMD.COM> tim@amd.com (Tim Olson) writes:
<	tot = a + b + c + d + e + f;
<where tot is a long and the others are shorts.  In this case, it is
<not sufficient to cast just one of the operands to a long, because the
<order of evaluation of the sums is undefined.  The standard widening
<rules apply only to the two operands of an operation, so if we cast
<only "a" to be a long, and the compiler chose to evaluate the sums
<from right-to-left, then only the last sum would be done with long
<operands.

Not true. The order of evaluation is undefined, but the *binding* is
defined. The binding is defined to be:
	tot = (((((a + b) + c) + d) + e) + f);
Thus if the expression is written as:
	tot = (long)a + b + c + d + e + f;
it is defined to be equivalent to:
	tot = ((((((long)a + b) + c) + d) + e) + f);
now we apply the standard integral promotions to get:
	tot = ((((((long)a + (long)b) + (long)c) + (long)d) +
		(long)e) + (long)f);
*NOW* the order in which the longs are added can be rearranged, but not
before!

Note also that:
	tot = a + b + c + d + e + (long)f;
is equivalent to:
	tot = (long)(a + b + c + d + e) + (long)f;
so beware.