🚀 go-pugleaf

In article <DG8y40.BMz@world.std.com> bobduff@world.std.com (Robert A
Duff) writes:

|> In article <45cj8d$red@ixnews3.ix.netcom.com>,
|> Mike Rubenstein <miker3@ix.netcom.com> wrote:
|> >	Finally, it is absurd to make elaborate security checks on debugging 
|> >	runs, when no trust is put in the results, and then remove them in 
|> >	production runs, when an erroneous result could be expensive or 
|> >	disasterous.  What would we think of a sailing enthusiast who wears 
|> >	his life-jacket when training on dry land but takes it off as soon as 
|> >	he goes to sea>
|> >
|> >From C, A, R, Hoare in "Hints on programming language design" in 

|> The analogy is bogus, IMHO.  Constraint checks don't save lives in the
|> same way as life jackets.  If the program gets Constraint_Error, what is
|> the pilot of the airplane supposed to do?!

If the program gets a ConstraintError, it aborts, the watchdog kicks
in, and the redundant system takes over.  On the other hand, if it
just reads a random value, it might very well put the plane in a dive,
and declare that all is well.

I've done a lot of critical systems (railway brake systems,
cardiological surveillance (English word, please?), etc.), and in
general, these are precisely the systems where bounds checking is most
essential.  You cannot afford not to.

|> Constraint checks just give the programmer a better idea of where to
|> start debugging.  So, IMHO, turning checks on during debugging, and off
|> (if necessary for speed), during production runs, makes perfect sense to
|> me.  Note the "if necessary".  Real-time systems care about time.  If
|> checking code is fast enough (and a good compiler will remove most
|> checks), then sure, leave it turned on.  But don't be fooled into
|> thinking that will make the system work properly in the presence of
|> bugs.

But it must.  Any large real system will have bugs.  Even human pilots
make errors.  But the airplane is not allowed to crash because of it.
This is why systems have redundancy (including both a pilot and a
co-pilot).  In real life, critical systems *must* be error tolerant.
-- 
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung