Re: JOB:Sr. SW Engineers Wanted-Fortune 500 Co

[Richard D Riehle <laoXhai@ix.netcom.com>]

In article <t7ln544nkz.fsf@calumny.jyacc.com>,
	Hyman Rosen <hymie@prolifics.com> wrote:

>We're (now) discussing the propriety of enabling runtime checks
>in production code. Ariane 5 makes a good example for discussion.
>What happens when proofs of behavior turn out, for whatever reason,
>to be wrong? When you code, you are always proving things, or else
>you would never be able to make any progress -
>
>	if a = 3 and then a = 3 and then a = 3 and then ...
>
>At some point, you must be satisfied that a condition for which
>you are checking holds. How much time and effort do you then devote
>to worrying about whether that condition *really* holds, and to
>writing code which will trigger if that condition does not hold?

Industrial engineers used to be taught to question whether 100%
checking was appropriate for 0.001% errors.  This notion led to
a question during a meeting I attended where we were planning the
architecture for a hospital laboratory software system.  One of
the system engineers asked, "Well, what is the probability of
this event occurring?"  The laboratory manager replied, "We cannot
rely on probability. We can kill people with this stuff."

Your example, an if ... end if statement suggests the need to encode
this checking in the program.  In his famous Turing lecture, Tony
Hoare criticized Ada for even having exception handling and suggested
the same approach: if there is a possibility of error, write your code
to detect and handle it rather than rely on some exception mechanism.

Ada 95 offers this option in the X'Valid attribute.  The question of
100% checking for 0.001% error needs to be asked each time one decides
to use X'Valid.  Ada (and Eiffel) Exception handling carries none
of the overhead associated with 100% error checking within the program
code.  The exception handler is invoked only when some variable fails,
at run time, to conform to its run-time profile.  

For example, should one check for divide-by-zero each time through a
iteration:

         for I in Data'Range loop
             X := some computed value using I;
             Y := X/Z;
         end loop;

Would it be proper to add code to ensure that the computation of X
could never be zero and process that code during every iteration? 
In a long running program, this would seem to be foolish to some,
essential to others.

In Arianne, the failure was in a piece of code that was short-lived
and had critical timing implications.  It would have been perfectly
OK to do the checking since the code would not be revisited again
during the mission.  That is 100% checking would have been very
inexpensive.  

We see the practice of turning off checks all the time in space
applications.  Software deployed on the MIL-STD 1750A almost always
has a pragma Suppress(All_Checks).  The reason given is the need for
reserve memory over and above that required for initial deployment.
It rarely has to do with timing factors.  In fact, in current 
design, it is assumed that space applications will be deployed with
All_Checks turned off.  This is probably a mistake with current
architectures and code optimizers, but has simply become the habit.

So your question, "How much time and effort do you then devote ..."
will be answered differently by the laboratory manager than by the 
engineering manager responsible for a communication satellite. 
In the case of Arianne 5, nobody asked the right questions or did
enough analysis to determine the correct answer to the right
questions, even if they had been asked.

Richard Riehle
richard@adaworks.com