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.1 required=5.0 tests=BAYES_05,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 12b42c,12d7915e86ce849c
X-Google-Attributes: gid12b42c,public
X-Google-Thread: 101deb,12d7915e86ce849c
X-Google-Attributes: gid101deb,public
X-Google-Thread: 103376,5f645669103080a8
X-Google-Attributes: gid103376,public
From: root@linux_pc.org (root)
Subject: Re: Ariane Crash (Was: Adriane crash)
Date: 1996/08/02
Message-ID: <DvI8Bz.Fw3@eskimo.com>#1/1
X-Deja-AN: 171542564
sender: news@eskimo.com (News User Id)
x-nntp-posting-host: tia1.eskimo.com
references: <4ta1vu$m1u@goanna.cs.rmit.edu.au> <4tiods$ehp@zeus.orl.mmc.com>
organization: Eskimo North (206) For-Ever
newsgroups: comp.lang.ada,comp.lang.pl1,rmit.cs.100
Date: 1996-08-02T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <4torim$ku8@goanna.cs.rmit.edu.au>,
	rav@goanna.cs.rmit.edu.au (++           robin) writes:
<snip>
>
>---Please read what I wrote.  The overflow was not a hardware
>fault.  It was a programming error that should not have occurred,
>bearing in mind the "sudden death" nature of the shutdown in the
>event of any kind of interrupt..

 ++robin, please read what the poster wrote ... he was describing a
 situation where, by spec, the event was deemed to indicate a hardware
 fault. We can all see clearly that it was not a hardware fault in this
 case; however that does not relieve the s/w of it's requirement to
 treat the event as indicative of a hardware fault.

 btw: A 'spec' is when a customer tells you what he thinks he wants.
      You may or may not agree with his interpretation of what he wants,
      but if you want the work, you promise to deliver what he SAYS! he
      wants - even if it is wrong - unless you can convince him to fix
      his wrong 'spec'. The embedded systems world uses 'spec' to
      define a 'design'; then customer gets to piss in the design as well.

<snip>
>---If you make an assumption about the range of data,
>and you are wrong, it is a programming error.
>

 Unless the 'spec'/'design' require you to make that assumption ...

<snip>
>---Again, the interrupt for fixed-point overflow was
>not expected to happen.  The software DID NOT OPERATE
>AS DESIGNED.  It failed.  You're placing too literal an
>interpretation on the first sentence.

 I believe the report clearly indicates that software operated per design.
 The fault lies with adapting existing software to a new mission, without
 doing sufficient system engineering to see where the old design needed
 to be beefed up to meet the new mission!

 Re: your favorite language & embedded systems ... is that all a troll,
     or what ?


                                           regards