Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!bu-cs!bloom-beacon!adam.pika.mit.edu!scs
From: scs@adam.pika.mit.edu (Steve Summit)
Newsgroups: comp.lang.c
Subject: Re: gcc vs. commercial C compiler (Sun's)
Message-ID: <9052@bloom-beacon.MIT.EDU>
Date: 2 Feb 89 06:29:18 GMT
References: <286@proton.UUCP> <2410@psivax.UUCP>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: scs@adam.pika.mit.edu (Steve Summit)
Distribution: usa
Lines: 37

In article <286@proton.UUCP> proton!nusbaum@ucrmath.ucr.edu (R. James Nusbaum) writes:
>Does anyone have any thoughts on the use of...a relatively new
>compiler as compilers go...where software failure could cause loss of life?

If you are writing life-critical software, YOU must be sure that
it is safe.  (Hal Schloss has already made this point; I am just
making it more strongly.)  You should no more assume that your
compiler is perfect than assume that your code is perfect: you
test your complete system exhaustively, and any bugs in the
compiler are found "automatically."  (This is not to say that
your test cases have to validate the entire compiler; you end up
testing only those language and compiler features that you use,
a set which by definition is embodied in your executable code,
which is what you are already testing.)

If your device fails and injures someone, and it is later shown
that the failure can be traced to a compiler error, it is still
your fault for not having caught the failure during evaluation.

In any case, there should be little or no truly life-critical
software.  Modern systems use lots of software for user-friendly
interfaces, but (in a properly designed system) user interface
software isn't life-critical.  Ideally, hardware (electronic or
mechanical) interlocks should prevent unsafe operation no matter
how confused the software gets.  Several people have voiced
extreme concern about the use of the software-controlled devices
being discussed.  For a device which does in fact depend on
"life-critical software," these fears are valid, but one should
not automatically shun any device with a microprocessor in it.

Patient safety is a difficult and complicated problem, and far
more than the software and its programmers is involved.  Anyone
who is interested in these issues should check out the RISKS
forum, which discusses this sort of thing all the time.

                                            Steve Summit
                                            scs@adam.pika.mit.edu