🚀 go-pugleaf

In article <KANZE.95Oct11123925@slsvgqt.lts.sel.alcatel.de>, kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) writes:
|> In article <DG8y40.BMz@world.std.com> bobduff@world.std.com (Robert A
|> Duff) writes:

[snippety snip snip-snip]

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

monitoring ?

|> general, these are precisely the systems where bounds checking is most
|> essential.  You cannot afford not to.

Absolutely.

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

How true. It seems to me that we cannot sensibly discuss all this without
understanding the categories we are talking about. I can see:

- safety-critical systems, real-time or not (airplanes, nuclear plants etc)
- real-time non-safety-critical systems (washing machines, dealing rooms)
- "the rest"

I agree with James, that for safety-critical systems checks have to remain
to switch to a fail-over system, or to arbitrate results between redundant
computations.

For real-time non-safety-critical systems, it could be argued that checks
can be removed. After all, how serious is it if a currency dealer gets
the wrong number on his screen (ok, millions could be lost, but compared with
an air crash, I personally believe this is insignificant. Others may disagree).

For "the rest", far far too few people seem to do real profiling. Over and
over again I have heard people say "we'll do such and such, because it's
faster". Then if you run empirical tests, to find out how much faster, you may
find the answer is "insignificantly faster". On my last project, empirical
testing showed that inline functions on the VAX/VMS system we were using
were *not* faster than out-of-line functions.

Sure, everybody likes to think their code is critical and has to run
as fast as possible. Unfortunately this is a gut reaction, and leads us
away from an objective approach to software quality.

Ian