I hate having to put on my language-lawyer hat, but here goes:
Jim Schram <[EMAIL PROTECTED]> writes:
> 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 isn't right. Type promotions within arithmetic expressions are
determined statically, from the expression context, not
dynamically. Order of evaluations doesn't affect 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.
x unsigned [int], y and z signed [int]:
(x + (signed long) (y - z) * 10)
Since y and z are signed, (y - z) has the type signed int. No promotions.
(signed long) (y - z) thus has the type signed long. Promotion from
signed int to signed long is trivial.
10 has type signed int, by the standard's rules for interpretation of
constants.
(signed long) (y - z) * 10 is then (type-wise):
[signed long] * [signed int].
The signed int is promoted to a signed long before the multiplication
takes place, and the result is a signed long.
x + (signed long) (y - z) * 10 is then:
[unsigned int] + [signed long].
Both of these are promoted to unsigned long by the rules discussed
previously.
Again, this process of type promotion is fully static. The fact that
the order of evaluation of some of this is undefined (by associativity
of + and *) doesn't affect the typing rules; they're associative as
well.
- Nathan
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palm.com/devzone/mailinglists.html
