[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