Re: Ariane 5 - not an exception?

[john@assen.demon.co.uk (John McCabe)]

rav@goanna.cs.rmit.edu.au (++           robin) wrote:
<..snip..>

>	>  2) PL/I

>	>     a) There is no PL/I compiler for the 1750A

>---Not an obstacle.  How was an Ada compiler written for it?

Because the US Military decided that their standard microprocessor
(Mil-Std-1750A) should have a compiler for their standard language Ada
(Mil-Std-1815).

>	>     c) This failure was not a language issue.

>---Isn't it?  One of the arguments put forward was that
>an Ada condition couldn't be raised and leave a trace,
>and that it would be argued that there was no guarantee
>whether a piece of code was executed.

Of course it isn't. How many people have to point out that no matter
what language had been used the specification and design was still
faulty.

>	> It is a management issue.
>	>        Specifically, it is a failure of engineering management.

>---There are lots of things for which one can blame 
>management, but the lack of a check for overflow has
>to come down to the programmer.

Read the report - the lack of checks was the result of analysis done
on the software and obviously was accepted at a higher level. The
important point being that the analysis was done and the checks
removed, _not_ that they weren't there in the first place.

>	>     d) Given the incorrect specifications against which the program was
>	>        designed, the same failure would have occurred in PL/I or any
>	>        other language.

>---No it wouldn't.  The lack of a test for overflow was
>the problem.  But even supposing for a moment that
>all conversions were checked, then
>an interrupt handler could be included for fixed-point
>overflow.  This would have trapped any unchecked
>overflow.  A R/T (and even non R/T) PL/I programmer
>routinely puts in error control.

Chances are that this is exactly how the Operand Error exception was
raised. Why don't you find out about Ada and how it is implemented in
embedded systems before stating rubbish like this. You may learn a
lot.

>	>  4) Software Reuse

>	>     If one intends to "reuse" software, such as Ariane 4xx software in
>	>     Ariane 5xxx, in a significantly different architecture, there is some
>	>     virtue in extensive testing.

>---In this case, with simulated inputs, and with SIGNAL
>statements to check out what happens when an interrupt
>occurs.  If this had been done (routine in PL/I), the
>effect of an unchecked conversion would have been observed.

It's obvious from the report that the testing was inadequate. If the
inputs had been simulated well, the exception would have been raised.

>	>  7) Ada

>	>     This is still the best language for doing this kind of system.

>---PL/I would be clearly better, as it meets the requirments
>for audit trails in program and system checkout (in addition
>to the other facilities that it offers).

Read the Ada manual. Every feature you have mentioned for PL/I is
available in Ada.



Best Regards
John McCabe <john@assen.demon.co.uk>