woof@psivax.UUCP (Harold C. ) (01/27/89)
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
friedl@vsi.COM (Stephen J. Friedl) (01/27/89)
In article <87081@sun.uucp>, swilson%thetone@Sun.COM (Scott Wilson) writes:
< Perhaps it's time for software vendors to include warnings such as
< Motorola lists in the 68020 manual:
<
< Motorola, Inc. general policy does not recommend the use of
< its components in life support applications where in a failure
< or malfunction of the component may directly threaten life or
< injury. Per Motorola Terms and Conditions of Sale, the user
< of Motorola components in life support applications assumes
< all risk of such use and indemnifies Motorola against all
< damages.
National Semiconductor does (did?) have this kind of disclaimer
in their *TTL* data books. I think you had to have a letter from
the president of NS before you could use their chips in any kind
of life-support system.
Steve
--
Stephen J. Friedl 3B2-kind-of-guy friedl@vsi.com
V-Systems, Inc. I speak for you only attmail!vsi!friedl
Santa Ana, CA USA +1 714 545 6442 {backbones}!vsi!friedl
Nancy Reagan on these *stupid* .signatures: "Enough already, OK?"cramer@optilink.UUCP (Clayton Cramer) (01/28/89)
In article <1034@vsi.COM>, friedl@vsi.COM (Stephen J. Friedl) writes: > In article <286@proton.UUCP>, nusbaum@meson.uucp (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? > > This might depend on who the survivors would prefer to sue: FSF or Sun... > > Stephen J. Friedl 3B2-kind-of-guy friedl@vsi.com This is not a trivial concern. I know of a certain company whose 8-bit processor Pascal libraries had an error in one of the math functions. A major chemical company was writing software using it and another vendor's compiler for process control. If they had put the first company's executable to work on a real plant, it might well have lead to explosion... I can well picture a jury's reaction to finding out that a software vendor used "free" software, vs. a commercial product. (Even if the free product wasn't at fault). I suspect the tendency would be to view such a company as flakey, amateurish, or ridiculously cheap. -- Clayton E. Cramer {pyramid,pixar,tekbspa}!optilink!cramer Disclaimer? You must be kidding! No company would hold opinions like mine!
seanf@sco.COM (Sean Fagan) (01/30/89)
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 forwarded this to Richard Stallman, and he asked me to post this in reply: ---- Begin rms.repl ---- I don't think that a 20% performance difference would outweight any danger of unreliability in software that people's lives depend on. GCC is probably still somewhat less reliable than the Sun C compiler. However, we are making reliability a high priority now, and I hope this will cease to be so in the next few versions. ---- End rms.repl ---- My, personal, opinion would be to try both (unless you had to pay for the Sun compiler, in which case you should decide *before* you get it), and try running reliability tests on it. Gcc *is* buggy, true, but Sun doesn't let me look at their bug reports (you know, the ones that are now into 32-bits for identification?), so I can't compare it from that point. -- Sean Eric Fagan | "What the caterpillar calls the end of the world, seanf@sco.UUCP | the master calls a butterfly." -- Richard Bach (408) 458-1422 | Any opinions expressed are my own, not my employers'.
lvc@cbnews.ATT.COM (Lawrence V. Cipriani) (01/31/89)
+In article <286@proton.UUCP>, nusbaum@meson.uucp (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?
Please tell us what hospitals buy your product so we may stay away from them.
--
Larry Cipriani, att!cbnews!lvc or lvc@cbnews.att.comis813cs@pyr.gatech.EDU (Cris Simpson) (01/31/89)
> lvc@cbnews.ATT.COM (Lawrence V. Cipriani) writes: >+In article <286@proton.UUCP>, nusbaum@meson.uucp (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? > >Please tell us what hospitals buy your product so we may stay away from them. I would be willing to bet that Sun would prefer that you not use their compiler. The way medical malpractice suits work, they clean out everybody along the way until they get to some real money. An apparent compiler bug could be very expensive. FYI: Motorola says that they do not recommend their components for life support applications. They say that using their components means you have agreed to assume all risk and indemnify them against damages. None of which would last a second in court. And so, the specter of STRICT LIABILITY arose from the swamp, and the engineers and managers were sore afraid. cris
lvc@cbnews.ATT.COM (Lawrence V. Cipriani) (01/31/89)
In article <3621@cbnews.ATT.COM> I write: ++In article <286@proton.UUCP>, nusbaum@meson.uucp (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? +Please tell us what hospitals buy your product so we may stay away from them. Or what the name of the pacemaker is. I have some elderly relatives I wouldn't want using it. Please don't offer me reassurances, they won't help. I've been in the software business a while and I haven't found a program yet I haven't been able to break. Life critical software makes me very nervous. Gcc is still being developed, and has many known bugs. There are special disclaimers on it above and beyond the standard GNU disclaimers, to that effect, so you probably don't want to use it anyway. -- Larry Cipriani, att!cbnews!lvc or lvc@cbnews.att.com
djones@megatest.UUCP (Dave Jones) (02/01/89)
>> 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? > > Please tell us what hospitals buy your product so we may stay away > from them. > I've seen this sort of thing on the net before, and frankly, I don't like it. Somebody is using some engineering technique or tool, or in this case, simply investigating the relative worth of a particular tool, and along comes the implication that the company produces bad product. The suggestion is completely unsupported by what has been posted here. I rather suspect that the correspondent has no direct knowledge of the quality control procedures being used, no knowledge of the software produced by the company, and indeed no knowledge about the company at all. All we know is that the correspondent is trying to make a rational, informed choice as to which compiler to use. And a compiler is only a programming _tool_. I can't say for sure, but given the nature of their business, I suspect that, as part of their quality assurance program, the company goes to great lengths to assure that the compiler has indeed produced correct code. In any case, it is certainly not my prerogative to suggest otherwise. Dave Jones
lvc@cbnews.ATT.COM (Lawrence V. Cipriani) (02/01/89)
In article <1324@goofy.megatest.UUCP>, djones@megatest.UUCP (Dave Jones) writes: > I've seen this sort of thing on the net before, and frankly, I don't > like it. Somebody is using some engineering technique or tool, or > in this case, simply investigating the relative worth of a particular > tool, and along comes the implication that the company produces bad > product. I've seen this sort of thing on the net before, and frankly, I don't like. Somebody makes a one sentence remark, and then someone jumps all over it and puts words in the others mouth. Your jumping to conclusions about my motivations. I'm a very conservative person when it comes to taking certain types of risks. Frankly, I'm not satisfied with the state of software technology well enough to be comfortable with a pacemaker being run by one. Okay, some things just won't exist without software, that's not the point. The point is, where possible, I'd rather sit on the sidelines and watch other people be the "first". You won't catch me being a parachute tester, or a hang glider tester. It just isn't worth it to me. You wanted an apology, okay. I'm sorry you're jumped to conclusions about my motivations. Try not to do it again. -- Larry Cipriani, att!cbnews!lvc or lvc@cbnews.att.com
barmar@think.COM (Barry Margolin) (02/02/89)
In article <1324@goofy.megatest.UUCP> djones@megatest.UUCP (Dave Jones) writes: >> Please tell us what hospitals buy your product so we may stay away >> from them. > Somebody is using some engineering technique or tool, or >in this case, simply investigating the relative worth of a particular >tool, and along comes the implication that the company produces bad >product. Thanks for saying what I wanted to say. In addition, if anyone out there thinks that there are no computers in modern, sophisticated medical equipment, he's fooling himself. And if you admit that there are computers out there, what magnificent programming tools do you think they're using? It's unlikely that there are bug-less compilers and assemblers out there (and even if there are, there's no way to tell which they are, because program verification technology is not up to the task). I'll wager many of them are written in assembler, by the way, which has me just as worried as knowing that they use Suns. So, if you don't think modern software technology is good enough for critical hospital equipment, I suggest you not get sick. Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
djones@megatest.UUCP (Dave Jones) (02/02/89)
From article <3684@cbnews.ATT.COM>, by lvc@cbnews.ATT.COM (Lawrence V. Cipriani): > You wanted an apology, okay. I'm sorry you're jumped to conclusions about > my motivations. Try not to do it again. > -- > Larry Cipriani, att!cbnews!lvc or lvc@cbnews.att.com There was no misunderstanding. I understood your motivations exactly as you described them in the followup. Yours truly, Dave Jones
scs@adam.pika.mit.edu (Steve Summit) (02/02/89)
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
mcdonald@uxe.cso.uiuc.edu (02/03/89)
>Boeing airplanes are a marvel >of safety and reliability as a result of such attention to detail. They are? Really? Attention to the detail of which side the burning engine is on? To which cargo hold the fire is in? Presumably, life-critical software would not be ruined by bugs in a compiler. I would see to it, were I so rash as to be in such a business, that, among other tests, there would be a group whose job it would be to examine the assembler output of the compiler to see that the compiler did its job right. I would attempt to have a group look at the output directly, without recourse to the source code, to try to figure out what it would do. There is probably a limit to the size of system where this could be done: pacemaker progarms on the possible side, Stars Wars on the impossible side, and an airplane somewhere in the middle. Doug McDonald
woof@psivax.UUCP (Harold C. ) (02/03/89)
In article <3684@cbnews.ATT.COM> lvc@cbnews.ATT.COM (Lawrence V. Cipriani) writes: >I'm a very conservative person when it comes to >taking certain types of risks. Frankly, I'm not satisfied with the state >of software technology well enough to be comfortable with a pacemaker >being run by one. Okay, some things just won't exist without software . . . Actually choosing pacemakers as the medical device to discuss here is interesting. The current state of the art in pacemakers is such that almost all of the ones being implanted today in the U.S. depend upon software in the "pacemaker programmer" to set internal pacemaker registers properly. Most of the newest pacemakers have microprocessors in them. So if you are really uncomfortable with the idea that your life may depend on software in the pacemaker system, I suggest you don't get one implanted as that is the only way you will be able to avoid it. (As the things stand now, most pacemaker system failures are due to hardware problems. These problems generally cause the pacemaker to cease pacing, which is only fatal if the underlying condition is fatal. Even if the software is infallible, I can't imagine any way to rule out all hardware failures.) -- 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
paulb@ttidca.TTI.COM (Paul Blumstein) (02/03/89)
I think that everyone is missing the point. First, no compiler is
completely bug-free. Second, most widely-available compilers (except
release 1.0 of anything :-) will work properly with non-funny code.
(If it doesn't, then the place where it is not working must be in the
funny class :-). Thirdly, a freshly-written application surely has its
own bugs (& don't call me surely :-).
Put the 3 items together & you (at least "I") conclude: The application,
being critical, better have a really good QA. This QA will find problems,
whether code-induced or compiler induced. Care in choosing the compiler
will only lessen the likelihood of having to debug down to the generated
code level (blech), not the likelihood of releasing a buggy product.
"I'm sorry Mrs. Smith, your husband died of a byte-swap error".
=============================================================================
Paul Blumstein | America may be unique in being a country which has
Citicorp/TTI | leapt from barbarism to decadence without touching
Santa Monica, CA | civilization. -- John O'Hara
+-------------------------------------------------------
{philabs,csun,psivax}!ttidca!paulb or paulb@ttidca.TTI.COM
If asked, Citicorp would say "Paul who?"les@chinet.chi.il.us (Leslie Mikesell) (02/05/89)
In article <9052@bloom-beacon.MIT.EDU> scs@adam.pika.mit.edu (Steve Summit) writes: >Ideally, hardware (electronic or >mechanical) interlocks should prevent unsafe operation no matter >how confused the software gets. This is an interesting concept (hardware being inherently more reliable than software) and perhaps true when comparing existing and well tested hardware to new software controlled devices. Is there any reason to believe that the hardware of a totally new device would be more reliable than the software? Les Mikesell
henry@utzoo.uucp (Henry Spencer) (02/09/89)
In article <225800115@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: >... I would see to it, were I so rash as to be in such a business, >that, among other tests, there would be a group whose job it would be >to examine the assembler output of the compiler to see that the compiler >did its job right. I would attempt to have a group look at the output >directly, without recourse to the source code, to try to figure out >what it would do... This sort of thing is not at all unknown in the avionics world, although it is not universal. Such groups normally work from the binary, by the way, so as to be absolutely sure that they are really looking at the code that will be executed. Assemblers aren't necessarily trustworthy either. -- Allegedly heard aboard Mir: "A | Henry Spencer at U of Toronto Zoology toast to comrade Van Allen!!" | uunet!attcan!utzoo!henry henry@zoo.toronto.edu