[M3devel] Integer overflow

[Tony Hosking]

If the type were INTEGER instead of CARDINAL then the current implementation *does* allow wrap-around.  I've fixed the range check so that overflow does not permit the bits for FIRST(INTEGER) to be stored in the CARDINAL.

On 11 Jan 2010, at 19:25, Rodney M. Bates wrote:

> If the type were INTEGER instead of cardinal, (and assuming no checking for overflows),
> I think wrapping around to the maximal negative value would be reasonable.  Even for
> CARDINAL, it's reasonable for the arithmetic operation itself (which is really being
> done in the full INTEGER range).  But then the assignment of the result back to the
> CARDINAL variable really must do a range check.  This derives from the assignment
> x:= ... in the WITH equivalent, not from the + 1 operation.
> 
> Mainly, there is a pervasive principle in the safety of the language that you can
> never get a bit pattern stored in a variable that does not map back to an abstract
> value of its type.  We really need to preserve this.
> 
> Tony Hosking wrote:
>> Even under the interpretation for INC that yields:
>> VAR s: CARDINAL := LAST(INTEGER);
>> BEGIN WITH x = s DO x := VAL(ORD(x) + 1, CARDINAL) END; END;
>> the compiler currently does not insert a bounds check, because it reasons that the bound for ORD(x) + 1 is [0+1, LAST(INTEGER)], so the result is always assignable to CARDINAL.
>> In reality, the compiler should presumably assume that because ORD(x) + 1 might overflow if ORD(x) = LAST(INTEGER) then the bound for the expression ORD(x)+1 is actually the same as INTEGER: [FIRST(INTEGER),LAST(INTEGER)].  So, because this is larger than the range for CARDINAL it really needs to insert a bounds check on the conversion to CARDINAL.
>> On 9 Jan 2010, at 23:33, Tony Hosking wrote:
>>> So, in my experiments with range checking on integers, I have been playing with the overflow case:
>>> 
>>> VAR s: CARDINAL := LAST(INTEGER);
>>> BEGIN INC(s) END;
>>> 
>>> Should this fail at runtime with a range check error?
>>> 
>>> The language definition says that integer overflow may or may not be checked, depending on the implementation.  (See FloatMode.i3).
>>> 
>>> If it is not checked, is it reasonable that s takes on the value FIRST(INTEGER)?
>>> 
>>> Antony Hosking | Associate Professor | Computer Science | Purdue University
>>> 305 N. University Street | West Lafayette | IN 47907 | USA
>>> Office +1 765 494 6001 | Mobile +1 765 427 5484
>>> 
>>> 
>>> 
>>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100111/33f19a51/attachment-0002.html>