long conversion of short expression.
Chris Torek
chris at mimsy.UUCP
Fri Aug 4 10:45:59 AEST 1989
>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
More information about the Comp.lang.c
mailing list