home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / lang / cplus / 18332 < prev    next >
Encoding:
Text File  |  1992-12-22  |  2.1 KB  |  53 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!gatech!darwin.sura.net!udel!rochester!rocksanne!news
  3. From: kirby@xerox.com (Mike Kirby)
  4. Subject: Re:  Give me safe C++
  5. Message-ID: <1992Dec22.182256.3797@spectrum.xerox.com>
  6. Sender: news@spectrum.xerox.com
  7. Reply-To: kirby@xerox.com
  8. Organization: Xerox Corporation, Webster NY
  9. References: <1992Dec21.234459.20895@ucc.su.OZ.AU>
  10. Date: Tue, 22 Dec 1992 18:22:56 GMT
  11. Lines: 40
  12.  
  13. In article 20895@ucc.su.OZ.AU, maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
  14. >In article <1992Dec18.134937.14313@bony1.bony.com> richieb@bony1.bony.com (Richard Bielak) writes:
  15. >>
  16. >>If you are writing safety critical software - let's say software that
  17. >>controls the brakes in *my* car - I'd rather have you code in PASCAL
  18. >>and run with all the runtime checks on. I don't want my brakes to stop
  19. >>working just because you forgot an ampersand.
  20. >>
  21. >    I'd rather have the code
  22. >implemented in a language in which all the run-time checks
  23. >had been optimised away by PROVING they were not required.
  24. >
  25. >    What would you have your brakes do if the run-time
  26. >checks detected a program error? I think if you lived
  27. >you would be entitled to sue the manufacturer.
  28. >-- 
  29. >;----------------------------------------------------------------------
  30. >        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
  31. >    Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
  32. >;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
  33.  
  34.  
  35. In most saftey critical systems, you ASSUME that there will be errors in the
  36. software.  With this assumption in mind, you create physical fail-safe's or
  37. programatic failsafes to ensure that specific problem states can never be
  38. entered.  
  39.  
  40. The problem with formal mathematical methods for proving software implementation,
  41. is that the proof only ensures that the implementation is a valid implementation
  42. of the requirements.  It does not ensure that the requirements are correct. 
  43. Faulty requirements will lead to failure, and formal proofs will NOT catch that.
  44.  
  45. This discussion is starting to drift out of the realm of C++ discussions thouugh..
  46.  
  47. Mike Kirby
  48. Xerox Corp
  49. E-mail: kirby.roch803@xerox.com
  50.  
  51.  
  52.  
  53.