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: 103376,fee8802cc3d8334d X-Google-Attributes: gid103376,public From: "Robert I. Eachus" Subject: Re: Ada and Java. different behaviour. casting long to int problem. Date: 1999/06/22 Message-ID: <37700CFC.94862F1C@mitre.org>#1/1 X-Deja-AN: 492697700 Content-Transfer-Encoding: 7bit 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> <7kg9is$85g@dfw-ixnews8.ix.netcom.com> <376E87D3.FA9FD42C@hso.link.com> X-Accept-Language: en Content-Type: text/plain; charset=us-ascii Organization: The MITRE Corporation Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 1999-06-22T00:00:00+00:00 List-Id: "Samuel T. Harris" wrote: > As has been said in this thread a couple of times, no feature > of the language was at fault either by it usage or by is > avoidance. The analysis, design, and implementation were all > based on the Ariane 4 flight trajectory and performance > characteristics. The practices employed are common and accepted > within the industry performed with due diligence as applied > to the Ariane 4. The problem was simply one of not reverifying > reused code in a new situation. Amen! Perfect software is no longer perfect if used outside its design envelope. > After reading the report, the only software bug I could discern > was the improper interpretation of diagnostic information provided > by the failed units to the central processer as _real_ attitude data. > That strikes me as a design/implementation flaw. But it was a deliberate design decision made for good and sufficient reasons. Since both processors output was covered by telemetry, dumping the internal state of the "failed" and ignored processor wouldn't hurt. The possibility of both processors getting to the same point was discussed at length. Because, on the Arianne 4, the only way to get there was either dual hardware failures, or the rocket being way outside its intended trajectory, the decision was made that capturing the data was fine, because the vehicle was about to be destroyed anyway. So it was known that the data dump would cause the missle to possibly go further off course, and it was accepted. And as I keep pointing out, none of this destroyed the Arainne 5. What did was that other reused software had the Arianne 4 center of gravity, moments, and structural data built in. The guidance computer sent data indicating that the Arianne 5 was off course. The correction applied was too great for the Arainne 5 stack (rocket stack not call stack ;-), and the stack came apart. This could have happened even if the guidance computer was operating "correctly." For example upper atmosphere winds could have caused the computers to apply a correction which was too big for the Arianne 5 with the same result. The single and only point of failure was that not only did management decide not to test the software or check it against Arianne 5 requirements, they even refused to let the original programming team SEE the Arianne 5 engineering specs. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is...