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.1 required=5.0 tests=BAYES_00,INVALID_MSGID, TO_NO_BRKTS_PCNT autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,885dab3998d28a4 X-Google-Attributes: gid103376,public From: "Marin David Condic, 407.796.8997, M/S 731-93" Subject: Re: Ariane 5 failure Date: 1996/10/01 Message-ID: <96100114390546@psavax.pwfl.com>#1/1 X-Deja-AN: 186548196 sender: Ada programming language comments: Gated by NETNEWS@AUVM.AMERICAN.EDU x-vms-to: SMTP%"INFO-ADA@VM1.NODAK.EDU" newsgroups: comp.lang.ada x-vms-cc: CONDIC Date: 1996-10-01T00:00:00+00:00 List-Id: Robert A Duff writes: >Alan Brain wrote: >>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. > >This reasoning doesn't sound right to me. The hardware part, I mean. >The reason checks-on costs only 5% or so is that compilers aggressively >optimize out almost all of the checks. When the compiler proves that a >check can't fail, it assumes that the hardware is perfect. So, hardware >faults and cosmics rays and so forth are just as likely to destroy the >RTS, or cause the program to take a wild jump, or destroy the call >stack, or whatever -- as opposed to getting a Constraint_Error a >reocovering gracefully. After all, the compiler doesn't range-check the >return address just before doing a return instruction! > Typically, this is why you build dual-redundant systems. If a cosmic ray flips some bits in one processor causing bad data which does/does not get range-checked, then computer "A" goes crazy and computer "B" takes control. Hopefully they don't *both* get hit by cosmic rays at the same time. The real danger is a common mode failure where a design flaw exists in the software used by both channels - they both see the same inputs and both make the same mistake. Of course trapping those exceptions doesn't necessarily guarantee success since either the exception handler or the desired accommodation could also be flawed and the flaw will, by definition, exist in both channels. If all you're protecting against is software design failures (not hardware failures) then obviously being able to analyze code and prove that a particular case can never happen should be sufficient to permit the removal of runtime checks. MDC Marin David Condic, Senior Computer Engineer ATT: 561.796.8997 M/S 731-96 Technet: 796.8997 Pratt & Whitney, GESP Fax: 561.796.4669 P.O. Box 109600 Internet: CONDICMA@PWFL.COM West Palm Beach, FL 33410-9600 Internet: CONDIC@FLINET.COM =============================================================================== "Some people say a front-engine car handles best. Some people say a rear-engine car handles best. I say a rented car handles best." -- P. J. O'Rourke ===============================================================================