From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 107079,eca28648989efca9 X-Google-Attributes: gid107079,public X-Google-Thread: 101deb,885dab3998d28a4 X-Google-Attributes: gid101deb,public X-Google-Thread: 103376,885dab3998d28a4 X-Google-Attributes: gid103376,public X-Google-Thread: f74ae,eca28648989efca9 X-Google-Attributes: gidf74ae,public From: Ken Garlington Subject: Re: Ariane 5 failure Date: 1996/09/28 Message-ID: <324D02FA.575A@lmtas.lmco.com>#1/1 X-Deja-AN: 185848194 references: <52a572$9kk@goanna.cs.rmit.edu.au> <52bm1c$gvn@rational.rational.com> <1780E8471.KUNNE@frcpn11.in2p3.fr> <1780FB1E3.KUNNE@frcpn11.in2p3.fr> content-type: text/plain; charset=us-ascii organization: Lockheed Martin Tactical Aircraft Systems mime-version: 1.0 newsgroups: sci.astro,sci.math.num-analysis,comp.lang.pl1,comp.lang.ada x-mailer: Mozilla 2.02 (Macintosh; I; 68K) Date: 1996-09-28T00:00:00+00:00 List-Id: Ronald Kunne wrote: > > In article > 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"