Re: Problems with Hardware, Languages, and Compilers

Jan Vorbrueggen <jan@fsnif.neuroinformatik.ruhr-uni-bochum.de>
21 Mar 1997 10:12:58 -0500

          From comp.compilers

Related articles
[6 earlier articles]
Re: Problems with Hardware, Languages, and Compilers rideau@ens.fr (Francois-Rene Rideau) (1997-03-16)
Re: Problems with Hardware, Languages, and Compilers robison@kai.com (Arch Robison) (1997-03-16)
Re: Problems with Hardware, Languages, and Compilers rideau@ens.fr (Francois-Rene Rideau) (1997-03-18)
Re: Problems with Hardware, Languages, and Compilers smryan@mail.com (1997-03-18)
Re: Problems with Hardware, Languages, and Compilers meissner@cygnus.com (Michael Meissner) (1997-03-18)
Re: Problems with Hardware, Languages, and Compilers dlmoore@ix.netcom.com (David L Moore) (1997-03-18)
Re: Problems with Hardware, Languages, and Compilers jan@fsnif.neuroinformatik.ruhr-uni-bochum.de (Jan Vorbrueggen) (1997-03-21)
| List of all articles for this month |

From: Jan Vorbrueggen <jan@fsnif.neuroinformatik.ruhr-uni-bochum.de>
Newsgroups: comp.compilers,comp.lang.misc,comp.arch.arithmetic
Date: 21 Mar 1997 10:12:58 -0500
Organization: Institut fuer Neuroinformatik, Ruhr-Universitaet Bochum, Germany
References: 97-03-037 97-03-041 97-03-057 97-03-073 97-03-103
Keywords: theory, errors

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
--


Post a followup to this message

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