[Shootout-list] Re: Integer overflow

[Brian Hurt]

On Thu, 23 Sep 2004, Brent Fulgham wrote:

> Based on this comment, I think you have been developing in an arena
> where the effects of overflow are not so catastrophic.  You don't have
> to work long in the financial world before you burn a few weekends
> fixing "unimportant" bugs like this because of errors like this.

You're right, I've never worked in the financial world.

> 
> Certainly it's nice that one can rely on overflow to mimic modular
> arithmetic for a specific application.  But I would imagine the times
> when this behavior is actually desireable, let alone forgivable, are not
> so common in the less glamorous world of safety-critical software.

I have, on the other hand, worked on software where if it failed, people 
could die.  One thing it taught me was to think about what you were doing, 
and types your variables are.

I have had to worry about overflows.  But I've had to spend a heck of a
lot more time worried about race conditions and deadlocks.  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.  
But both problems pale in comparison to the amount of time I've had to
spend worrying about memory allocation problems.

I can see where having unlimited precision integers could solve some 
problems (and introduce others).  I don't even mind having that being one 
of the attributes limited- personally, I think it'd be interesting to see 
how it'd affect performance (the top tier performance languages- C, C++, 
SML, Ocaml- all have fixed precision integers).

I just can't see it being *the* criteria for language safety, which is 
what I'm seeing advocated from where I sit.

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
Brian