[gclist] Safeness

Darius Blasband darius@phidani.be
Mon, 13 May 1996 15:30:35 +0200 (MET DST)


 
 > I think we're confusing issues here.  The applications I write are not safety
 > critical.  If I had to write a safety critical application, I would trust none
 > of:
   
 (A few items removed here...)
 
 > 
 > 4. A C++ compiler or its output.  (I might trust a C compiler after manually
 > checking its output, and verifying that in addition to being correct, it met
 > required resource constraints.  At least at present, I usually have too much
 > trouble reading C++ compiler output.)
 
 Because you don't trust the output of a C compiler, you rather rely on your
 own ability to find errors and eventually, to correct them. The problem is
 that there is a limit in terms of size and complexity of the systems you
 can master yourself or even in large teams. The only way you can hope to
 master this kind of complexity is by raising the level of abstraction, hence,
 accepting some basic blocks (these basic blocks are the paradigm) as secure.
 For many complex systems, a GC is one of the ways of raising this abstraction
 level.
 
 Otherwise, despite the amount of work you invest in trying to make your systems
 safe, you'll be order of magnitude worse that whatever stupid code has been
 generated by a C compiler.
 
 If you take your point a bit too far, you'll even have to check the MP 
 microcode manually. Why would you trust it more than the output of a C
 or C++ compiler ? Remember the pentium floating point bug. 
 
 I am afraid security is only a relative issue. There is no such thing as
 100% safeness. We try to do our best, and reduce risks as far as possible,
 but aiming at zero defect (hardware and software) by removing so-called
 uncontrollable items such as GC or C compiler will only make things worse.
 
 In my opinion, at least...
 
 Regards,
 
 Darius