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: 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: rgilbert@unconfigured.xvnews.domain (Bob Gilbert)
Subject: Re: Ariane 5 - not an exception?
Date: 1996/08/23
Message-ID: <4vk8r4$2r7@zeus.orl.mmc.com>#1/1
X-Deja-AN: 176015053
references: <4vgmit$124@goanna.cs.rmit.edu.au>
organization: The unconfigured xvnews people
reply-to: rgilbert@unconfigured.xvnews.domain
newsgroups: comp.software-eng,comp.lang.ada,comp.lang.pl1
Date: 1996-08-23T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <4vgmit$124@goanna.cs.rmit.edu.au>, rav@goanna.cs.rmit.edu.au (++           robin) writes:
> 
> ---No, the specification wasn't faulty.

I disagree, I think the specification was faulty, and is the
primary cause of the problem.

>  The implementation
> was.  Because of a programming error, a data conversion from
> double precision floating-point to a 16-bit integer
> overflowed.  In the absence of a check, an exception occurred,
> the immediate action of which was to shut down the processor.

Exactly as the requirements specified, and the software performed
exactly to the specification, including saving into PROM the
current state.  It is the specification which wrongly assumed that
a data overflow would indicate a probably hardware failure, and if
a hardware failure occurred the action was to shut down the allegedly
failed equipment.

> That shutdown resulted in the inevitable and almost immediate
> destruction of the project.  Read the report.

>    If you had read the report, you would have notected that
> the committee could not find any explanation in the code
> as to why this & 2 other conversions did not have checks,
> while all the other similar conversions in the vicinity
> did.  There is the suggestion that the checks were overlooked.

Actually I think they suggested that there was weak documentation
in the code noting that an analysis of the conversions was
performed.  It is my impression that they concluded that an
analysis of the conversions was done, and a conscious decision to 
omit them was (wrongly) made, in part to meet their 80% processor
utilization goal (something some have suggested should have been
waived in this circumstance).

>   john@assen.demon.co.uk (John McCabe) writes:
> 	>The important point being that the analysis was done and the 
> 	>checks removed, _not_ that they weren't there in the first place.
> 
> ---On the contrary, if you read the report, it states
> clearly and unequivocally that the analysis was done
> and the checks *added* where they felt that they were 
> needed (NOT removed from ones that they felt did not
> need it).

I think the above poster meant that the checks were removed from the 
requirements specification, maybe?

As you say, an analysis was done and checks added where they felt it
was necessary.  Sounds like the analysis, which determined the
requirements, was in error.  The code was written and performed
per the faulty specification, that's not a programming error, and
certainly not a language issue.

-Bob