Gabriel Sechan wrote:
From: Andrew Lentvorski <[EMAIL PROTECTED]>
The bug is in handling integers. There are two options for integer
overflow:
1) Die. Period. Do not silently truncate, overflow, saturate, or
whatever.
2) Gracefully degrade. Switch to a slower version of integer which
can handle the greater required precision. eg. Lisp bignums, Python
longs, or Java BigInteger.
I wish language designers would just finally get it through their
heads that int's should have infinite precision and floating point
numbers should be *decimal* floating point instead of *binary*
floating point.
It would save *so* much time and trouble.
Disagree completely. I refuse to pay the performance hit to check for
overflow and deal with it. Its a corner case that happens in less
than .1% of additions, probably an order of magnitude less. Not owrth
optimizing for. For the infrequentness that any program needs to deal
with this, you'd save all the debugging time it required in the past
60 years in one minute of all the computer users in the world waiting
due to the overhead.
A rational system is to have checking by default, and allow the
programmer to specify that they'd like overflow checking to be disabled.
In the case of integer math, most hardware *is* actually doing almost
all the work for overflow checking by default anyway (for example, on an
x86 the overflow register is updated to reflect that an overflow
happened). Checking really just adds an extra instruction to the
operation, and in the case where the check passes may not actually add
any kind of a performance hit after all the hardware's tricks are done.
The problem is that C/C++/Java don't have a standard way to check that
register, so you have to instead write some time consuming code that
checks based on the input values.
Even smarter would be for the compiler figure out cases where overflow
isn't possible, and disable the checking for those cases.
--Chris
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
