Re: Ariane 5 failure

[Ken Garlington <garlingtonke@lmtas.lmco.com>]

Ronald Kunne wrote:
> 
> In article <mheaney-ya023180002609962252500001@news.ni.net>
> mheaney@ni.net (Matthew Heaney) writes:
> 
> >>The problem of constructing bug-free real-time software seems to me
> >>a trade-off between safety and speed of execution (and maybe available
> >>memory?). In other words: including tests on array boundaries might
> >>make the code saver, but also slower.
> 
> >Why, yes.  If the rocket blows up, at the cost of millions of dollars, then
> >I'm not clear what the value of "faster execution" is.  The rocket's gone,
> >so what difference does it make how fast the code executed?  If you left
> >the range checks in, your code would be *marginally* slower, but you'd
> >still have your rocket, now wouldn't you?
> 
> Despite the sarcasm, I will elaborate.
> 
> Suppose an array goes from 0 to 100, and the calculated index is known
> not to go outside this range. Why would one insist on putting the
> range test in, which will slow down the code? This might be a problem
> if the particular piece of code is heavily used, and the code executes
> too slowly otherwise. "Marginally slower" if it happens only once, but
> such checks on indices and function arguments (like squareroots), are
> necessary *everywhere* in code, if one is consequent.

I might agree with the conclusion, but probably not with the argument.
If the array is statically typed to go from 0 to 100, and everything
that indexes it is statically typed for that range or smaller, most
modern Ada compilers won't generate _any_ code for the check.

I still believe the more interesting issue has to do with the _consequences_
of the check. If your environment doesn't lend itself to a reasonable response
to the check (quite possible in fail-operate systems inside systems that move
really fast), and you have to test the checks to make sure they don't _create_
a problem, then you've got a hard decision on your hands: suppress the check
(which might trigger a compiler bug or some other problems), or leave the check in 
(which might introduce a problem, or divert your attention away from some other
problem).

-- 
LMTAS - "Our Brand Means Quality"