🚀 go-pugleaf

In article <14804@nigel.udel.EDU> new@udel.edu (Darren New) writes:
>In article <1990Mar22.181947.27026@maths.nott.ac.uk> you write:

	I guess "you" is "me"!

>>Or are you
>>talking about the inherent insecurities of the "malloc ... free" model
>>of heap storage?  If so, this again applies to Pascal, but not to other
>>languages with proper heap mechanisms.  In any case, it's a solved
>>problem.

>What about Pascal makes the heap "insecure"?  It is perfectly possible
>to have good checking of pointers in Pascal.  The first Pascal
>compiler I used would detect [... first example deleted ...]
>It would also detect
>   new(p); q := p; dispose(p); new(p); xx := q^;
>[... by using counters ...]

	Well, first off, it's hard to make this scheme unspoofable.  If
you have something like:

	new(p); q := p; dispose(p); ...; new(x); ...

where the space for "x" encloses the space for "p", and you now assign
things into that space, how do you know you haven't accidentally created
a legal thing for "q" to point at?  OK, it's a small chance [but not
helped if the counter is indeed the number of calls of "new", and thus
likely to be a small integer].  Clever coding of the library routines
and of the compiler can get around this, especially if the hardware is
on your side.

	Secondly, this technique separates the error from its detection.
The error is to call "dispose" while "q" is live;  the next actual use of
"q" may be right the other end of the program, and it could be disguised
by copying "q" into other pointers, and the "dispose" could be of a copy
of "p", tucked away in some insignificant-looking sub-sub-procedure, etc.
My memory of Pascal is too rusty to be sure whether the above call of
"dispose" is technically illegal, or whether it's only dereferencing "q"
that's illegal.  If the former, then that too could be detected by better
library routines and compilers, but I expect it's the latter, in which
case giving the poor user decent diagnostics is virtually impossible.

	Thirdly, the decision of when to free storage should not be one
for the programmer.  It's intrinsic to heap storage that the freeing is
dissociated from the creation.  It's intrinsic to the more complex data
structures that storage may be linked together in arbitrarily complicated
ways.  So there is no way [except in very simple programs] in which a
procedure can take a decision, based on localisable information, about
which parts of the structures should be freed.  Even when this information
is available, it can be very tedious to keep "fingers" on obsolescent
storage just so that it can be freed eventually.  I conclude that garbage
collection really has to be a matter for the system.

	Fourthly, all this checking takes space and time, so it's the
first thing to go in a production version.  (What was it that Dijkstra
said about using a lifebelt while paddling in the harbour and throwing
it away while swimming out to sea?)  Proper garbage collection costs
nothing in the compiled code [given shared libraries] and little in speed
until the store becomes full;  and it's secure.  Good software engineering.

-- 
Andy Walker, Maths Dept., Nott'm Univ., UK.
anw@maths.nott.ac.uk