long conversion of short expression.

[Chris Torek]

>In article <18795 at mimsy.UUCP> I noted that
>>The result of shortvar*shortvar has type int. ... If the result
>>overflows, the value is undefined; a clever int-is-16-bits-style 68000
>>compiler [might omit an extl instruction in a subsequent conversion to
>>long, yeilding the `right' value].  This is not required by any C standard,
>>but is permitted since the result value is undefined.

In article <4750 at omepd.UUCP> prl at inteloa.intel.com (Philip Lantz) writes:
>I agree that if the multiplication overflows, the result is undefined,
>but its type is still an int; if a later conversion to long is
>required, isn't the compiler required to perform the 'extl' anyway?
>That is, shouldn't the result of a conversion from int to long be in
>the numeric range of an int, even if the original int value was
>undefined?  Or is the compiler free to do whatever it likes with an
>entire expression if any sub-expression overflows?

The last is more or less true: as long as the compiler always produces
the right answer when asked to do things that are defined (such as `300
* 65 => 19500', which cannot overflow---the pANS requires that `int' be
at least 16 bits), it can do anything it wants when the result is
implementation-defined or undefined.  I like to use ridiculous actions,
such as having the computer explode, or change into a butterfly, as
examples of permitted behaviour.

(Incidentally, you really could rig a computer to explode on arithmetic
overflow, particularly if it has an exception for such events.  But I
have not figured out how to change one into a butterfly.  I keep getting
Luna moths. :-) )
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris at mimsy.umd.edu	Path:	uunet!mimsy!chris