Is this a bug in Turbo C 2.0?

[Walter Bright]

In article <29446 at amdcad.AMD.COM> tim at 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.