Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!rutgers!bpa!cbmvax!uunet!psivax!woof
From: woof@psivax.UUCP (Harold C. )
Newsgroups: comp.lang.c
Subject: Re: gcc vs. commercial C compiler (Sun's)
Message-ID: <2410@psivax.UUCP>
Date: 26 Jan 89 18:45:36 GMT
References: <286@proton.UUCP> <36669@oliveb.olivetti.com>
Reply-To: woof@psivax.UUCP (Harold C. ( Hal ) Schloss)
Distribution: usa
Organization: Pacesetter Systems Inc., Sylmar, CA
Lines: 61

In article <36669@oliveb.olivetti.com> chase@Ozona.UUCP (David Chase) writes:
>In article <286@proton.UUCP> proton!nusbaum@ucrmath.ucr.edu (R. James Nusbaum) writes:
>>Does anyone have any thoughts on the use of gcc (a relatively new
>>compiler as compilers go) vs. using Sun's C compiler in a medical
>>software project where software failure could cause loss of life?
>
>I'd much rather hear that you were really interested in a compiler
>because of the bug-free code and fabulous debugging and testing tools.
>But, given that you asked for advice:
>
>I'm not sure that I would use C, period. . . . . .
 (David goes on to describe that many of the code problems are his, but
  no compiler is bug free.)

What I do for a living is create software for pacemaker programmers. Others
in this company create software for pacemakers themselves. (A pacemaker
programmer is an external (outside the body) device that allows doctors
to monitor the functioning of a pacemaker and adjust the pacemaker's
settings.) While the pacemaker programmer software I write is unlikely
to cause a loss of life, it is certainly could if circumstances were just
right.

We write all of our software in C. We don't do that because is C is any
more safe than any other langauge, because you really cannot guarantee
that any compiler for ANY language will generate code perfectly. (I have
NEVER heard of a bug free compiler for any language.) We write in C because
that is the most convient and portable language that runs on all our platforms.

The main issue here is that any program or system that is going to be used
in a life support application has to be tested. Here we do testing of both
hardware and software. The hardware is tested when a product is first created,
by subjecting to temperature, humidity, and vibration extremes. This testing
is done in-house and by outside testing labs. Our software is tested by two
groups. The first group is composed of people involved in writing software
for that product. This testing is planned in advance and the results of all
the tests are documented. The second test group is composed of a completely
independent team at out company that does nothing but test our products. They
too have a test plan and complete documentation of the results. (We also
have several groups in-house that do informal "beta" testing prior to either
of the aforementioned groups formal testing. Our "beta" testers, as well as
our formal testers, do all of their work with pacemakers connected to
electrical simulations of the human body. No testing is done involving
pacemakers already implanted in patients.)

Our tests find bugs. By knowing what the most mission critical steps or
procedures our software is used for, we can concentrate on quite thoroughly
vetting those procedures and steps. Even this does not guarantee that the
software is perfect. I am not sure if there is any way to guarantee it.

In conclusion, what I am saying is that the choice of language of compiler
for a medical program is governed by the same criteria as would be used for
any kind of program. The main issue is that any medical program or device
needs to be thoroughly tested by as many different teams as possible.
So if gcc produces more efficient code, then I would use it. No matter
what I used, I would test the final program in as many ways as pratical
before using it in a situation where it could cause a loss of life.
-- 
	Hal Schloss	 Pacesetter Systems Inc., A Siemens Company
 {sdcrdcf|ttidca|hacgate|nrcvax|jplpro|hoptoad|csun|quad1|harvard|csufres|
  bellcore|uunet|rdlvax|ashtate|siemens|cetacea|dbase|otto|logico}!psivax!woof
  ARPA: woof@psivax.psi.siemens.com or woof@rdlvax.rdl.com