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.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 101deb,6f286718fe3c2efe,start
X-Google-Attributes: gid101deb,public
X-Google-Thread: 103376,885dab3998d28a4
X-Google-Attributes: gid103376,public
From: rav@goanna.cs.rmit.edu.au (robin)
Subject: Re: Ariane 5 failure
Date: 1996/11/08
Message-ID: <55ucvc$msi$1@goanna.cs.rmit.edu.au>#1/1
X-Deja-AN: 195212240
references: <96102813151485@psavax.pwfl.com> <32765410.F6A@lmtas.lmco.com>
organization: Comp Sci, RMIT, Melbourne, Australia
newsgroups: comp.lang.ada,comp.lang.pl1
nntp-posting-user: rav
Date: 1996-11-08T00:00:00+00:00
List-Id: <comp.lang.ada>


	Ken Garlington <garlingtonke@lmtas.lmco.com> writes:

	>Marin David Condic, 561.796.8997, M/S 731-93 wrote:
	>> 
	>> robin <rav@GOANNA.CS.RMIT.EDU.AU> writes:
	>> >---The issue was not the addition of a new exception handler.
	>> >The issue was that a magnitude check should have been
	>> >performed on a conversion from double precision floating
	>> >point to 16-bit integer, but it wasn't.
	>> >Of course, having an exceptin handler for this specific purpose
	>> >would have helped, and should have been included as a fallback.
	>> >
	>> >        >Assuming that a new exception _handler_ had been added, then it _might
	>> >made
	>> >        >a difference.
	>> >
	>> >You can be absolutely certain that it would have helped.
	>> >
	>>     procedure ARIANE_FIVE_OPERATION is
	>>         X   : FLOAT range -65536.0..65535.0 := 65535.0 ;
	>>         Y   : INTEGER range -32768..32767 := 0 ;
	>>     begin
	>>         if (X not in -32768.0..32767.0) then
	>>             SHUT_DOWN_THE_CHANNEL_AND_PASS_CONTROL_TO_THE_OTHER_SIDE ; --Boom!
	>>         else
	>>             Y := INTEGER (X) ;
	>>         end if ;
	>>     end ARIANE_FIVE_OPERATION ;
	>> 
	>>     *Absolutely* certain?

---Absolutely.  The Report stated that the best estimate of the
value could have been used.

Thus:

   IF X > 32767 THEN
	Y = 32767;
   ELSE IF X < -32767 THEN
	Y = -32767;
   ELSE
	Y = X;

but back to the point, which you've missed apparently, which is that
the overflow could have been trapped (locally), as a fallback:

with a simple ON FIXEDOVERFLOW statement.

	>Well, in PL/I, it won't permit an exception handler to shut down the channel. :)

	>>     Seems that the above algorithm *DOES* have runtime checks to
	>>     constrain the assignment of a float to an integer, yet the
	>>     accommodation is still a *BAD* engineering decision.

You have to be joking.

	>> We can polish
	>>     and polish and polish the software all we want and perform all
	>>     sorts of runtime checks, but if the accommodation remains wrong,
	>>     we're polishing a turd.
	>> 
	>>     MDC
	>> 
	>> Marin David Condic, Senior Computer Engineer    ATT:        561.796.8997
	>> M/S 731-96                                      Technet:    796.8997
	>> Pratt & Whitney, GESP                           Fax:        561.796.4669
	>> P.O. Box 109600                                 Internet:   CONDICMA@PWFL.COM
	>> West Palm Beach, FL 33410-9600                  Internet:   CONDIC@FLINET.COM