Re: Arithmetic overflow [was Re: the benefits of immutability]

["James Y. Knight" <address@hidden>]

On Tuesday, August 19, 2003, at 04:09  PM, Perry E. Metzger wrote:
> The pathetic thing about Java is that not only is it crippled to make
> it safe, but it isn't even safe. Overflows, for example, are ignored,
> presumably to make it look more like C. Yuck.

You're talking about a different definition of safe. Java is safe in 
that you can safely run random code downloaded off the internet on your 
local machine without it being able to send out spam to everyone on the 
planet, upload all your personal information to the author, and then 
erase your hard drive. It is not safe against writing incorrect code. 
However, it does have many features that make it *easier* to write 
correct code (e.g. garbage collection, required exception handling).

Perhaps arithmetic overflow detection should have been added. It 
certainly could be nice. However, I suspect Sun decided the cost was 
too great, since, AFAIK current processors don't have the ability to 
trap on integer overflow. Thus, after every single integer operation, 
it would need to do a conditional jump on the overflow condition 
register flag. Certainly doable, though not very efficient.

However, the big question is: what should it do when there is an 
overflow? If it throws an exception (RuntimeException subtype 
presumably so you don't need to declare it on every function), at least 
programs will fail loudly, but you'll have to write your code much more 
carefully to actually be able to continue working as there are now many 
more possible sites for an exception to occur. Silently truncating the 
number to INT_MAX/INT_MIN is not any better than wraparound. Of course, 
the best answer would be to not ever use int/long and always use 
BigInteger, but that's currently impractical in Java due to the poor 
speed of BigInteger and the excess code you'd have to insert everywhere 
to convert the BigInteger back to an int/long.

James