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 11:50:52 PST
Path: 
 archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.icl.net!newsfeed.fjserv.net!kibo.news.demon.net!demon!news2.euro.net!ash.uu.net!spool.news.uu.net!not-for-mail
Date: Tue, 22 Jul 2003 14:50:26 -0400
From: Hyman Rosen <hyrosen@mail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.5a) Gecko/20030611 Thunderbird/0.1a
X-Accept-Language: en-us, en
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: Ariane5 FAQ
References: <mailman.26.1058753354.24167.comp.lang.ada@ada.eu.org>
 <1058799152.775376@master.nyc.kbcfp.com>
 <bfh2gb$eeiv4$1@ID-175126.news.uni-berlin.de>
 <1058810510.375902@master.nyc.kbcfp.com>
 <bfhaed$e786b$1@ID-175126.news.uni-berlin.de>
 <1058813341.841940@master.nyc.kbcfp.com>
 <bfhe55$eqglr$1@ID-175126.news.uni-berlin.de>
 <1058816605.566685@master.nyc.kbcfp.com>
 <bfhjjr$eftm1$1@ID-175126.news.uni-berlin.de>
 <AY0Ta.14787$0F4.7550@nwrdny02.gnilink.net>
 <20619edc.0307221029.47fe6d31@posting.google.com>
In-Reply-To: <20619edc.0307221029.47fe6d31@posting.google.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Organization: KBC Financial Products
Message-ID: <1058899826.878512@master.nyc.kbcfp.com>
Cache-Post-Path: master.nyc.kbcfp.com!unknown@nightcrawler.nyc.kbcfp.com
X-Cache: nntpcache 3.0.1 (see http://www.nntpcache.org/)
NNTP-Posting-Host: 204.253.250.10
X-Trace: 1058899826  5215 204.253.250.10
Xref: archiver1.google.com comp.lang.ada:40662
Date: 2003-07-22T14:50:26-04:00
List-Id: <comp.lang.ada>

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.

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.

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.