[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