Re: C.A.R. Hoare on liability

["Robert I. Eachus" <rieachus@attbi.com>]

Robert Dewar wrote:

  
> Three comments
> 
> First, runtime checks can be deadly if you have not done proper
> analysis of how they can be handled, since they can turn trivial errors that
> would not intefere with overall correct function into disasters (Ariane5 is
> an example of this in action).


I agree with the point, but not the example.  For Ariane 4, the analysis 
was carried out, and whether or not you agree with the final decision 
for Ariane 4, the decision was well thought out.  The disaster was that 
the Araine 4 analysis was carried out absent the Ariane 5 requirements 
for political reasons, and the Ariane 5 requirements analysis was never 
done.

Was it the first TriAda where I first heard that the problem with reuse 
is that the Mark II tank is not the same as the Mark I tank?



> Second, in safety critical code you often turn run time checks off,
> because you rely on other means to ensure that these checks can never fail.
> See for example the work that Praxis has done in proving programs to be
> exception free. With such a proof in hand, run time checks can be a menace for
> certification since you have a whole bunch of useless deactivated code.


Agreed, but see above.  The analysis must be redone for reuse.

 
> Third, there are situations in which the extra overhead from runtime checks,
> small though it may be, is unacceptable. It is no use saying to someone, sorry
> we know that if the checks could be turned off, you could use Ada just fine,
> but we have decided in Ada 0X that it was a terrible idea to allow people to
> do this, so you will have to use C instead.


Agreed, and I really like the methods you use in GNAT.  If code depends 
on a particular exception, explicitly turn it on in the code.  If code 
depends on some exception not occcuring, turn the check off.  That way 
changes in global settings don't affect the correctness of the program.


> For example, I would think that project files that describe the required
> compilation options should be under very strict configuration control, and
> not something that can casually be modified by someone who does not know
> what they are doing.


Definitely right.  But the problem is that if you drop the configuration 
change request on some VP's desk for his signature, you are likely to 
get hauled on the carpet if not fired.  Or worse yet, the VP will sign 
off without doing the engineering analysis needed.  Look at what 
happened on Challenger.  The engineer on the spot refused to sign off, 
and a corporate VP two time zones away--and not a licensed professional 
engineer--signed off on the boosters and faxed the OK to NASA.

(NASA should not have gone along with this.  But this was the first 
shuttle flight where an engineer was not in the NASA chain of command. 
Beggs had been asked to step aside due to some accounting irregularities 
on government programs while he was on the Board of Directors at 
Lockheed.  The acting head of NASA was not an engineer, and by the time 
Beggs was cleared, it was too late.)