[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