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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,fee8802cc3d8334d X-Google-Attributes: gid103376,public From: Marin David Condic Subject: Re: Ada and Java. different behaviour. casting long to int problem. Date: 1999/06/17 Message-ID: <376906CF.109EEF55@pwfl.com>#1/1 X-Deja-AN: 490683210 Content-Transfer-Encoding: 7bit Sender: condicma@bogon.pwfl.com References: <7jt2c0$vrb@drn.newsguy.com> <7k57vb$1ipf@drn.newsguy.com> <3766650F.705125B7@pwfl.com> <7k64t7$igo$1@its.hooked.net> <7k689a$ci2@drn.newsguy.com> <3766C842.E1EAB60A@pwfl.com> <3766D1CC.D712895E@itools.symantec.com> <7k8nn5$qcb$1@its.hooked.net> <3767E8A2.EF1A0570@itools.symantec.com> <7k8tv3$3gm@drn.newsguy.com> <7kaa6o$nr3$2@wanadoo.fr> Content-Type: text/plain; charset=us-ascii Organization: Pratt & Whitney Mime-Version: 1.0 Reply-To: diespammer@pwfl.com Newsgroups: comp.lang.ada Date: 1999-06-17T00:00:00+00:00 List-Id: Jean-Pierre Rosen wrote: > Please read the report. > The Ariane 501 failure was caused by the *removal* of a necessary > check. > Ada then diagnosed correctly the error, and did what the > specifications required it to do in this case: it made a memory dump > which was interpreted by the flight computer as positionnal data. > You can't blame the language for doing exactly what was in the > specification; the specifications were wrong. > Of course, without overflow checking, you would'nt have triggered the > incorrect behaviour required by the specification, but I don't think > this can be taken as an argument against overflow checking... This is a debate which has gone on before and you may be letting the toothpaste get out of the tube. ;-) IMHO, the *real* problem was not anything to do with language features - it was a fundamental management problem. They decided to use a piece of very successful, reliable software in a different application and never bothered to verify that it would work correctly given an entirely new and different set of requirements. The code which "broke" was only the immediate cause, but not the fundamental reason. In my understanding, they explicitly removed runtime checks from the code in question because of performance issues (not at all uncommon) but then went and validated that the code would never see anything out of range given the flight profile of the Ariane 4 rocket. Hence, the code was safe. Moving the code to Ariane 5 which had a different flight profile changed the requirements - but the code was never tested against those requirements. Hence the disaster. MDC -- Marin David Condic Real Time & Embedded Systems, Propulsion Systems Analysis United Technologies, Pratt & Whitney, Large Military Engines M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600 ***To reply, remove "bogon" from the domain name.*** Visit my web page at: http://www.mcondic.com/