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: 101deb,885dab3998d28a4 X-Google-Attributes: gid101deb,public X-Google-Thread: 103376,885dab3998d28a4 X-Google-Attributes: gid103376,public X-Google-Thread: 107079,eca28648989efca9 X-Google-Attributes: gid107079,public X-Google-Thread: f74ae,eca28648989efca9 X-Google-Attributes: gidf74ae,public From: Ken Garlington Subject: Re: Ariane 5 failure Date: 1996/09/27 Message-ID: <324BBE48.7DF0@lmtas.lmco.com>#1/1 X-Deja-AN: 185683290 references: <52a572$9kk@goanna.cs.rmit.edu.au> <52bm1c$gvn@rational.rational.com> <1780E8471.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-27T00:00:00+00:00 List-Id: Ronald Kunne wrote: > > In article <52bm1c$gvn@rational.rational.com> > rlk@rational.com (Bob Kitzberger) writes: > > >Ada _has_ range checks built into the language. They were explicitly > >disabled in this case. > > 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. Particularly for fail-operate systems that must continue to function in harsh environments, memory and throughput can be tight. This usually happens because the system must continue to operate on emergency power and/or cooling. At least until recently, the processing systems that had lots of memory and CPU power also had larger power and cooling requirements, so they couldn't always be used in this class of systems. (That's changing, somewhat.) So, the tradeoff you describe can occur. The trade-off I find even more interesting is the safety gained from adding extra features vs. the safety _lost_ by adding those features. Every time you add a check, whether it's an explicit check or one automatically generated by the compiler, you have to have some way to gain confidence that the check will not only work, but won't create some side-effect that causes a different problem. The effort expended to get confidence for that additional feature is effort that can't be spent gaining assurance of other features in the system, assuming finite resources. There is no magic formula I've ever seen to make that trade-off - ultimately, it's human judgement. -- LMTAS - "Our Brand Means Quality"