[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