Re: Problems with Hardware, Languages, and Compilers

David L Moore <dlmoore@ix.netcom.com> writes:


> > Else, they might end like the European space agency,
> > with a rocket that explodes out of a floating point overflow.
>
> This is an unfair characterisation of what actually happened.


Quite.


> If you read the report, which can be found on the European Space Agency web
> site (sorry, I don't have the URL), you will see that the software
> worked perfectly. More precisely, the unit that caused the failure did
> so because it was working exactly as designed, and, in addition, the
> design was not in any way flawed.


Yes, but that is only the case because a design based on no
specification is trivially correct; that doesn't make it useful or
correct in any practical sense. I'd also argue that the design, such
as it was, was flawed, because it implements a fail-fail paradigm
(based on the assumption that all failures are uncorrelated and caused
by hardware), instead of fail-operate. The additional bug of having
flight control interpret diagnostic data as flight data only made
things more, uhm, "interesting".


> [This is comp.risks rather than comp.compilers material. -John]


I agree to a large extent. However, part of the problem with Ariane 5
was that a large amount of effort was spent to analyse the properties
of the code and make delicate use of some of the more obscure features
of Ada to protect against certain eventualities - but it turns out
that all this effort was based on a specification that was
inapplicable (as it was based on the Ariane 4 flight profile) and
flawed in certain key aspects to begin with (not the ones mentioned
above - the routine that caused the error should have been modified
not to run after lift-off even for Ariane 4). But maybe that _is_ what
makes is comp.risks material.


Jan
--

Return to the comp.compilers page.
Search the comp.compilers archives again.