[Shootout-list] Re: Integer overflow

Brent Fulgham bfulg@pacbell.net
Thu, 23 Sep 2004 19:57:10 -0700


On 2004-09-23 07:43:58 -0700 Brian Hurt <bhurt@spnz.org> wrote:

> On Wed, 22 Sep 2004, Peter Hinely wrote:
> 
>> Yes, exactly!  So I proposed adding column to the pages giving a very
>> coarse-grained display of what classes mistakes the entry allows.
> 
> Can I sugest we change it from a security focus to a feature focus?  
> Several 
> important features have little or nothing to do with security.
> 
> My short list of features:
> - primary paradigm: procedural(C, Perl)/OO (C++, Java)/functional 
> (Lisp,
> ML) 
> - Garbage collectiong type: non-gc (C/C++), reference counting, 
> [generational-]marking&sweep, [generational-]copying
> - Execution style: native (C/ocaml), virtual machine (Java/ocamlb), 
> interpreted (perl)

Good ideas.  We already have the interpreted/native shown as plain 
text/bold italic,
but this could be made clearer.

>> You dismissed integer overflow as not being important. If you feel 
>> that
>> way, fine, but you don't have to force your view on every visitor to 
>> the
>> Shootout pages.
> 
> What boggles my imagination is why it's considered that important.

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.

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.

-Brent