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,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,f039470e8f537101 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-07-22 13:47:21 PST Path: archiver1.google.com!postnews1.google.com!not-for-mail From: snarflemike@yahoo.com (Mike Silva) Newsgroups: comp.lang.ada Subject: Re: Ariane5 FAQ Date: 22 Jul 2003 13:47:20 -0700 Organization: http://groups.google.com/ Message-ID: <20619edc.0307221247.30165bbf@posting.google.com> References: <1058810510.375902@master.nyc.kbcfp.com> <1058813341.841940@master.nyc.kbcfp.com> <1058816605.566685@master.nyc.kbcfp.com> <20619edc.0307221029.47fe6d31@posting.google.com> <1058899826.878512@master.nyc.kbcfp.com> NNTP-Posting-Host: 154.6.152.68 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1058906840 20300 127.0.0.1 (22 Jul 2003 20:47:20 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 22 Jul 2003 20:47:20 GMT Xref: archiver1.google.com comp.lang.ada:40669 Date: 2003-07-22T20:47:20+00:00 List-Id: Hyman Rosen wrote in message news:<1058899826.878512@master.nyc.kbcfp.com>... > Mike Silva wrote: > > The code was written to handle every possible value of the parameter > > properly. Why you refuse to acknowledge this is a mystery. > > Because this was not the case. The code was written to handle the > limited range of parameters correctly, by doing a conversion from > floating-point to 16-bit integer without any guard against overflow. > > When the Ariane 5 data caused an overflow, this same unprotected > conversion caused an operand fault, which the rest of the system > then interpreted as the computer itself being broken. Which was the intended behavior. There was a project bias that any unhandled errors were presumed to indicate hardware failure. > > Notice that it's extremely unlikely that the top range of the > Ariane 4 value exactly corresponded to the maximum integer value > of the conversion output. That means that there was a range from > the top Ariane 4 value to the top non-overflowing value where the > software would have behaved one way, and a range above the > overflowing value where it would have behaved a different way. That's right, but it doesn't change anything. Maybe the Ariane 4 developers were perfectly happy to let those particular "impossible" values pass through the system, or maybe they should have caught them as well. That doesn't change the fact that the system behaved as designed and intended for the overflowing values. > > The software worked as specified when the input was limited to > the specified range. Out of that range, the software worked in a > random, undefined manner. The behavior of the module over the entire possible range of inputs was neither random nor undefined.