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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,7e8cebf09cf80560 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!feeder2.cambriumusenet.nl!feed.tweaknews.nl!195.208.113.1.MISMATCH!goblin3!goblin.stu.neva.ru!exi-transit.telstra.net!news.telstra.net!exi-spool.telstra.net!exi-reader.telstra.net!not-for-mail From: "robin" Newsgroups: comp.lang.ada References: <4d80b140$0$43832$c30e37c6@exi-reader.telstra.net><4d814af0$0$43831$c30e37c6@exi-reader.telstra.net> <4d8200cb$0$43837$c30e37c6@exi-reader.telstra.net> <8ueh3mF3rgU1@mid.individual.net> Subject: Re: How would Ariane 5 have behaved if overflow checking were not turned off? Date: Sat, 19 Mar 2011 08:13:10 +1100 X-Newsreader: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Message-ID: <4d8475d4$0$43834$c30e37c6@exi-reader.telstra.net> NNTP-Posting-Host: 123.3.27.205 X-Trace: 1300526548 exi-reader.telstra.net 43834 123.3.27.205:1030 Xref: g2news2.google.com comp.lang.ada:19279 Date: 2011-03-19T08:13:10+11:00 List-Id: Niklas Holsti wrote in message <8ueh3mF3rgU1@mid.individual.net>... >robin wrote: >> Simon Wright wrote in message ... >>> "robin" writes: >>> >>>> But only if the error was hardware, which it wasn't. >>> No, and it wasn't bloody software either!!! >> >> I'm afraid that it was (software). >> Consider this: If just ONE unprotected overflow occurs, >> the mission is lost. > >No. If the unprotected overflow occurs because of a hardware fault or >noise in one computer only, the mission continues with the other computer. If there is a problem with one computer, the mission continues with the other computer, as you say. However, if an unprotected overflow occurs at any of those 3 unprotected conversions from float to integer, the mission is doomed. >> Not a SINGLE unprotected conversion should have been included. > >You are being rather dogmatic about this, Robin... Justifiably so, because it's a real time system. One programming mistake is all it takes. >>> it was SYSTEM DESIGN!!! and >>> no amount of faffing about at the edges of software will ever fix that. >> >> The fact remains that in that real-time system, >> unprotected conversions were included. > >After analysis of their possible causes and effects. In the Ariane 4. > >> No-one experienced in real-time programming >> would have permitted those unprotected conversions. > >Do you claim to know that the Ariane 4 software developers were >inexperienced? Inexperienced in programming real time systems. >The designers analysed the situation, decided what the software should >do in case of overflow at this point, and built the software >accordingly. When the overflow happened in the Ariane 501 launch the >software did exactly what the designers had decided it should do in this >case. Not really; They overlooked what would happen if overflow occurred. >The argument about what the software should have done instead can be >endless, and perhaps useful for developing other programs, but does not >make the Ariane 4 software incorrect. A bug is something that goes wrong when you don't expect or plan for it. >The ESA report makes several recommendations to increase robustness, for >example to activate only those software functions that are needed in >each phase of a mission. The Ariane 5 designers instead followed the >KISS principle "if it isn't broken, don't fix it". The software contained a bug. Just because it didn't fail in Ariane 4 doesn't mean there's not a bug. > Unfortunately >"broken" is relative and depends on the environment. The software wasn't >broken for the Ariane 4, but was broken for the Ariane 5. I claim that it was broken for both. For real-time software, it was buggy for the Ariane 4.