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.2 required=5.0 tests=BAYES_00,FROM_LOCAL_HEX, FROM_STARTS_WITH_NUMS autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,7e8cebf09cf80560 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news4.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: "Vinzent Hoefler" <0439279208b62c95f1880bf0f8776eeb@t-domaingrabbing.de> Newsgroups: comp.lang.ada Subject: Re: How would Ariane 5 have behaved if overflow checking werenotturned off? Date: Thu, 17 Mar 2011 23:51:20 +0100 Message-ID: References: <4d80b140$0$43832$c30e37c6@exi-reader.telstra.net> <4d814af0$0$43831$c30e37c6@exi-reader.telstra.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Trace: individual.net mUpuaSKdya3hGyyIarV2yAo4cevdFJFSGDDXPHi9yUn1WdP1CG Cancel-Lock: sha1:ubZo7utc5phGOp1RLI6RvPA1SAQ= User-Agent: Opera Mail/11.01 (Win32) Xref: g2news2.google.com comp.lang.ada:19265 Date: 2011-03-17T23:51:20+01:00 List-Id: 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. 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 - 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? Vinzent. -- A C program is like a fast dance on a newly waxed dance floor by people carrying razors. -- Waldi Ravens