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: g2news1.google.com!news1.google.com!goblin2!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> Subject: Re: How would Ariane 5 have behaved if overflow checking were not turned off? Date: Sat, 19 Mar 2011 08:13:44 +1100 X-Newsreader: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Message-ID: <4d8475d5$0$43834$c30e37c6@exi-reader.telstra.net> NNTP-Posting-Host: 123.3.27.205 X-Trace: 1300526550 exi-reader.telstra.net 43834 123.3.27.205:1030 Xref: g2news1.google.com comp.lang.ada:18309 Date: 2011-03-19T08:13:44+11:00 List-Id: Vinzent Hoefler <0439279208b62c95f1880bf0f8776eeb@t-domaingrabbing.de> wrote in message ... >robin wrote: > >> Vinzent Hoefler <0439279208b62c95f1880bf0f8776eeb@t-domaingrabbing.de> wrote in message ... >>> robin wrote: >> >>> 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. > >For Ariane 4 it _was_ reasonable. > >>> 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. > >It was. The wrong hardware was connected to the system. > >>> Again. In the Ariane 4 it would have been exactly that. A hardware error. >> >> Again, you are making a false assumption. > >It's not an assumption. > >>> There was no freaking way, Ariane 4 could have exceeded the safe range. >> >> recall Murphy, "If anything can go wrong, it will". > >Yes, of course. That applies to all countermeasures, too. Murphy's Law >implies there will be more ways to screw you than there will be to prevent >just that. > >I've heard of critical systems which read and write variables through a >driver layer doing the load and stores redundantly and checking for >possible memory corruption on the way. Still, even those can fail. > >Well, at least they do it very slowly, because the performance drops >significantly. ;) > >>>>> 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. > >No. It handled it according to the specification. So the specification was to guarantee failure? They chose not to protect three data conversions, thinking that it [overflow] couldn't happen. They set protection up for four other similar conversions, but not for the one in question (nor for two others). Because those three data conversions [from floating-point to 16-bit signed integer] were not protected, they could raise an overflow exception. One of them did, and thus guaranteed failure of the mission. >Specwise the overflow could only be interpreted as a hardware fault >at that point. A reboot (what a lot of systems would try) would take >too long for the system, so the requirement was to cease operation. >And it did exactly that. _Any_ error handler would have been required >to do that - The job of the programmer was to prevent such an error occurring. The four other similar conversions HAD protection, so it wasn't as you say, namely, that "overflow could only be interpreted as a hardware fault". > and the one in place (which was just the default handler) >did it quite as well as any other. > >You're trying to blame the software for following its specification? It wasn't following the specification. It was important that such a conversion error be protected, and not to shut down the system.