[Shootout-list] Re: Integer overflow
Brent Fulgham
bfulg@pacbell.net
Sat, 25 Sep 2004 19:53:56 -0700
On 2004-09-25 14:28:12 -0700 Brian Hurt <bhurt@spnz.org> wrote:
> And, having tracked both down, I can state authoratively that
> tracking down an
> overflow isn't nearly the problem that tracking down a race condition
> is.
Agreed. Perhaps what we should have a concurrency test. Right now,
we have
the producer/consumer threads test, which isn't exactly right since it
was originally
designed to show the cost of forking new processes. Perhaps a
concurrent test
(which could be done via processes or threads) would be a good
example. If we
made it devious enough, it could be a good test of these issues.
> But both problems pale in comparison to the amount of time I've had to
> spend worrying about memory allocation problems.
Me too.
> I just can't see it being *the* criteria for language safety, which
> is what
> I'm seeing advocated from where I sit.
Well, I can't speak for anyone else. I'm just pointing out that a
test that requries the
numbers in a file to be added up to a particular total can't be
considered "successful"
if it is allowed to overflow.
Whether overflow moves from "bug" to "safety issue" depends on what is
done with
the output.
-Brent