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: 103376,885dab3998d28a4 X-Google-Attributes: gid103376,public X-Google-Thread: 101deb,885dab3998d28a4 X-Google-Attributes: gid101deb,public X-Google-Thread: f74ae,eca28648989efca9 X-Google-Attributes: gidf74ae,public From: bobduff@world.std.com (Robert A Duff) Subject: Re: Ariane 5 failure Date: 1996/09/29 Message-ID: #1/1 X-Deja-AN: 186023988 references: <1780FB1E3.KUNNE@frcpn11.in2p3.fr> <324F1157.625C@dynamite.com.au> organization: The World Public Access UNIX, Brookline, MA newsgroups: sci.astro,sci.math.num-analysis,comp.lang.pl1,comp.lang.ada Date: 1996-09-29T00:00:00+00:00 List-Id: In article <324F1157.625C@dynamite.com.au>, 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! - Bob