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, PP_MIME_FAKE_ASCII_TEXT autolearn=no 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,UTF8 Path: g2news1.google.com!news3.google.com!feeder.news-service.com!feeder.news-service.com!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> Subject: Re: How would Ariane 5 have behaved if overflow checking werenotturned off? Date: Thu, 17 Mar 2011 10:46:52 +1100 X-Newsreader: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Message-ID: <4d814af0$0$43831$c30e37c6@exi-reader.telstra.net> NNTP-Posting-Host: 123.3.23.56 X-Trace: 1300318960 exi-reader.telstra.net 43831 123.3.23.56:1040 Xref: g2news1.google.com comp.lang.ada:18272 Date: 2011-03-17T10:46:52+11:00 List-Id: Vinzent Hoefler <0439279208b62c95f1880bf0f8776eeb@t-domaingrabbing.de> wrote in message ... >robin wrote: >> Vinzent Hoefler <0439279208b62c95f1880bf0f8776eeb@t-domaingrabbing.de> wrote in message ... >>> Elias Salomão Helou Neto wrote: > >>>> Since then I have been wondering. If compiler checking where actually >>>> turned on, what would have happened? > >>> The same, according to the specification. > >>>> How could it avoid the disaster? > >>> Not at all. > >> On the contrary., an error handler would have performed >> something useful. >Precisely what? The _only_ reasonable action at that point was to assume >a hardware error and shutdown the computer. For Ariane 4, that is. Whether Ariane 4 or 5, it was not reasonable to assume that the error was hardware. See my post elsewhere. >> The crux of the matter is that the data bus would not have been >> loaded with an error number [which was then treated as guidance data]. >AFAIK this was required in case both systems died. And as we know, they >did exactly that. But only if the error was hardware, which it wasn't. > I'd assume the possibility of two hardware errors at >the same time were considered remote. >>> By handling it exactly the way it was supposed to be: > >>> Assuming a hardware error and leave control to the redundant subsystem. > >> That was the major blunder that they made, >> namely, treating a programming error as a hardware error. >> By doing that, they guaranteed failure of the mission. >Again. In the Ariane 4 it would have been exactly that. A hardware error. Again, you are making a false assumption. >There was no freaking way, Ariane 4 could have exceeded the safe range. recall Murphy, "If anything can go wrong, it will". >>> Which one, if any, is close to reality? > >>> As it has been mentioned here many times before, the software behaved >>> exactly as specified and it is very unlikely that _any_ error handling >>> could have avoided the problem > >> An error handler would have rescued the mission. >Only if were not behaving according to the specification. That means if >it were buggy - It was buggy. It didn't handle the overflow.