[Shootout-list] Safety vs. speed
Peter Hinely
phinely@hawaii.edu
Wed, 22 Sep 2004 15:05:55 -1000 (HST)
On Wed, 22 Sep 2004, Brian Hurt wrote:
> > Have I not been talking about the tests themselves? It's not whether a
> > language is unsafe, it's whethere the benchmark entry in that language
> > compiled with whatever flags it was compiled with is unsafe.
>
> So a C test that actually did bounds checking on array access would be
> considered "safe", but an Ocaml program compiled with -unsafe would not?
Common C implementations do no bounds-checking on array access. All C
entries would be marked "bounds-checking-unsafe".
>
> > That's why I put it in a different paragraph. I don't get your point. Any
> > non-trivial program is going to use integers (and maybe wrongly assume
> > that no overflow has occurred).
>
> And in real program, overflows are rarely seen.
Rarely seen or rarely happen? There's a difference. Do you know of any
research that backs up your assertion? I would be interested to know
about it.
Depending on how you define "rarely", one could say that dangling pointers
and memory leaks rarely happen too.
> You generally run into
> other constraints counting things long before you hit overflow problems.
> I don't recall ever needing to calculate 230! in a real program- if I did,
> I'd probably do it in FP.
100000 * 100000 will overflow in plenty of programs.
Unintended overflow can be the consequence of all sorts of bit twiddling:
int x = 1;
x << 33;
can overflow.
Regards,
Peter