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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC 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: Alan Brain Subject: Re: Ariane 5 failure Date: 1996/09/29 Message-ID: <324F1157.625C@dynamite.com.au>#1/1 X-Deja-AN: 185986636 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: @Home mime-version: 1.0 reply-to: aebrain@dynamite.com.au newsgroups: sci.astro,sci.math.num-analysis,comp.lang.pl1,comp.lang.ada x-mailer: Mozilla 3.0 (Win16; I) Date: 1996-09-29T00:00:00+00:00 List-Id: Ronald Kunne wrote: > 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. Why insist? 1. Suppressing all checks in Ada-83 makes about a 5% difference in execution speed, in typical real-time and avionics systems. (For example, B2 simulator, CSU-90 sonar, COSYS-200 Combat system). If your hardware budget is this tight, you'd better not have lives at risk, or a lot of money, as technical risk is appallingly high. 2. If you know the range is 0-100, and you get 101, what does this show? a) A bug in the code (99.9999....% probable). b) A hardware fault. c) A soft failure, as in a stray cosmic ray zapping a bit. d) a faulty analysis of your "can't happen" situation. As in re-use, or where your array comes from an IO channel with noise on.... Type a) and d) failures should be caught during testing. Most of them. OK, some of them. Range checking here is a neccessary debugging aid. But type b) and c) can happen too out in the real world, and if you don't test for an error early, you often can't recover the situation. Lives or $ lost. Brain's law: "Software Bugs and Hardware Faults are no excuse for the Program not to work". So: it costs peanuts, and may save your hide. ---------------------- <> <> How doth the little Crocodile | Alan & Carmel Brain| xxxxx Improve his shining tail? | Canberra Australia | xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM ---------------------- o OO*O^^^^O*OO o oo oo oo oo By pulling Maerklin Wagons, in 1/220 Scale