(Sorry about not threading, I wasn't subscribed when the original thread
happened)
Regardless of the what the default behaviour ends up as. I would suggest having
the different semantics associated with a different integer type. In Mozilla
code we have a CheckedInt type which has behaviour
These scenarios result in the loss of precision (overflow errors can be
delayed), but since task failure is non-recoverable precision doesn't
seem to me to be that important anyway.
Yes, that should help. Since we don't have shared mutable state there is
more opportunity to delay the checks.
Hi everyone,
I've been wondering for a while whether it's feasible from a performance
standpoint for a systems language to detect and abort on
potentially-dangerous integer overflows by default. Overflow is an
insidious problem for several reasons:
(1) It can happen practically anywhere;
On Apr 16, 2011, at 8:22 AM, Patrick Walton wrote:
On 04/15/2011 11:20 PM, Patrick Walton wrote:
This area seems promising enough that I was wondering if there was
interest in something like this for Rust. There's no harm in having the
programmer explicitly be able to turn off the checking at
Based on the experience with the tracer, overflow checks aren't really crazy
expensive and we can optimize them quite well. It probably depends on how well
LLVM understands them. I know it has intrinsics for it.
Andreas
On Apr 16, 2011, at 1:14 AM, Brendan Eich wrote:
On Apr 16, 2011, at
On 11-04-16 4:20 AM, Andreas Gal wrote:
Based on the experience with the tracer, overflow checks aren't really crazy
expensive and we can optimize them quite well. It probably depends on how well
LLVM understands them. I know it has intrinsics for it.
The checks themselves are not that
