At 8:12 AM +1000 2000/02/18, Stephen Best wrote:
>You've lost me ... what has order of evaluation of subexpressions got to do
>with it?
It means mixing signed and unsigned arithmetic is just a really bad idea! ;o)
I think I understand the issue, so here's a stab at an alternate explanation:
The order in which promotion of intermediate integers to signed or unsigned types
within expressions is unspecified, according to the ASNI spec. The accuracy of the
result depends entirely on the order of evaluation of the subexpressions' intermediate
promotions, thus the side-effects of mixing signed and unsigned arithmetic are
indeterminate when one of the components of the subexpression violates another
components' dimension (the sign dimension in this example).
This is somewhat similar to mixing short and long integers in an expression and
dealing with the potential overflow/underflow that may result. To avoid it, you have
to be explicit in the order you want each subexpression evaluated, or use data types
that do not involve any "silent" promotions.
Another way of looking at this, if x is unsigned but y and z are signed, is that [x +
(signed long) (y - z) * 10] generates results which depend on the order each
subexpression is evaluated during compilation, e.g. [(signed long) (y - z) * 10 + x]
versus [10 * (signed long) (y - z) + x] versus [x + 10 * (signed long) (y - z)] and
so forth are all allowed to generate different results according to ANSI because of
the side effects of mixing signed and unsigned integers.
None of this violates any casting or integer conversion rules; it's a silent sign
promotion problem during expression evaluation. Ain't broke. Nothin' to fix.
Does that help?
Regards,
Jim Schram
3Com/Palm Computing
Partner Engineering
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palm.com/devzone/mailinglists.html
