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,f96f757d5586710a X-Google-Attributes: gid101deb,public X-Google-Thread: 103376,5ac12f5a60b1bfe X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,5ac12f5a60b1bfe X-Google-Attributes: gidf43e6,public From: Steve O'Neill Subject: Re: Ariane 5 - not an exception? Date: 1996/08/13 Message-ID: <3210E4B5.475B@sanders.lockheed.com>#1/1 X-Deja-AN: 173952497 references: <4t9vdg$jfb@goanna.cs.rmit.edu.au> <31FE35BC.1A0D@sanders.lockheed.com> <4totv7$o9f@goanna.cs.rmit.edu.au> <32065615.77C7@sanders.lockheed.com> <4up6jg$h3e@goanna.cs.rmit.edu.au> content-type: text/plain; charset=us-ascii organization: Sanders, A Lockheed-Martin Company mime-version: 1.0 newsgroups: comp.software-eng,comp.lang.ada,comp.lang.pl1 x-mailer: Mozilla 2.01 (Win16; I) Date: 1996-08-13T00:00:00+00:00 List-Id: ++ robin wrote: I previously said: > > So they set about picking > >> and choosing which conversions to protect. > to which ++ robin replied: > ---This doesn't sppear specifically in the report as regards > this conversion and the 2 others in the vicinity. There's > the impliciation that these conversions were overlooked. > In any case, the test would have introduced a trivial > number of additional instructions. Well, here's what the report said: "It has been state that to the Board that not all of the conversions were protected because a maximum workload target of 80% had been set for the SRI computer. To determine the vulnerability of unprotected code, an analysis was performed on every operation which could give rise to an exception, including an Operand Error. In particular, the conversion of floating point values to integers was analysed and operations involving seven variables were at risk of leading to an Operand Error. This led to protection being added to four of the variables, evidence of which appears in the Ada code. However, three of the variables were left unprotected. No reference to justification of this decision was found directly in the source code. Given the large amount of documentation associated with any industrial application, the assumption, was essentially obscured, though not deliberately, from any external review. The reason for the three remaining variables, including the one denoting horizontal bias, being unprotectedwas that further reasoning indicated that they were either physically limited or that there was a large margin of safety, a reasoning which in the case of the variable BH turned out to be faulty. It is important to note that the decision to protect certain variables but not others was taken jointly by project partners at several contractual levels." So, what this tells us is that they did what they thought was a thorough analysis and consciously made the decision to leave 3 variables unprotected. An that this was not a unilateral decision. I'm not saying that this whole approach made sense. What I am saying is that this scenario is independent of the language used. Yes, in hindsight, it would have been much easier to add a couple lines of code even if it did cost 0.01% of that margin? and ++robin continues to profess: > > ---As I stated, a PL/I programmer experienced in real-time > programming, would not have made this stupid mistake. > And with this point I will continue to disagree. I guess that I need to learn PL/I since it obviously automatically endows people with god-like powers of reasoning that makes it impossible for them to build flawed systems. Wow, I wonder if NASA and the FAA know this?! ;) ++robin> ---You do not appear to have grounds for this opinion. Well, everyone has grounds for their opinions - it's called belief and it's mostly based on their experiences. My experiences obviously differ from yours therefore we have different opinions. Probably neither mine nor yours is entirely right or entirely wrong. And with that I think I'll stop my participation in this thread. -- Steve O'Neill | "No,no,no, don't tug on that! Sanders, A Lockheed Martin Company | You never know what it might smoneill@sanders.lockheed.com | be attached to." (603) 885-8774 fax: (603) 885-4071| Buckaroo Banzai