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: 103376,7e8cebf09cf80560 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.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 were not turned off? Date: Sun, 20 Mar 2011 11:42:57 +0100 Message-ID: References: <4d80b140$0$43832$c30e37c6@exi-reader.telstra.net> <4d814af0$0$43831$c30e37c6@exi-reader.telstra.net> <4d8475d5$0$43834$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 8wsgYfBfMmJoVqpeIU8SDwF8wAvfj51ouXcpFWB1SBwiCzdQsO Cancel-Lock: sha1:pVUqf0OH4uZUa0PqdhLKn2yxWFw= User-Agent: Opera Mail/11.01 (Win32) Xref: g2news1.google.com comp.lang.ada:18325 Date: 2011-03-20T11:42:57+01:00 List-Id: robin wrote: > So the specification was to guarantee failure? If you want to put it that way, yes. If Ariane 4 would have encountered such a value in _both_ SRIs, the safest assumption at this point would have been a complete failure. Mission aborted, all doomed. > They chose not to protect three data conversions, thinking that it [overflow] > couldn't happen. NO. They did not protect it, because they knew if the overflow happened, it must have been a hardware problem. > 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. Yes. What's your point? >> 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, Because they were more likely to happen under certain circumstances. > so it wasn't as you say, namely, that "overflow could only be > interpreted as a hardware fault". It was precisely that. If the digital speedometer in your car suddenly jumps from say 100 mph to 32767 mph, what would you assume? A hardware fault (in the sensor preferrably) or a real reading? >> 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. On the contrary. It was not specified to continue flight beyond operation limits. Vinzent. -- A C program is like a fast dance on a newly waxed dance floor by people carrying razors. -- Waldi Ravens