🚀 go-pugleaf

In article <1990Mar22.181947.27026@maths.nott.ac.uk> you write:
>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 both of the following:
   new(p);
   q := p;
   dispose(p);
   xx := q^;
because the block that q pointed to would be marked as "free" (or the
memory page would be unallocated if everything else on it was free too).
It would also detect
   new(p);
   q := p;
   dispose(p);
   new(p);
   xx := q^;
even if p reallocated the same space.  Each pointer had a counter in it
that indicated the number of times that "new" had been called when this
pointer was created, as did each heap block.  Thus, the counter in
q would mismatch the counter in the block that q pointed to, hence causing
a run-time message.   

Uninitialized pointers were cause by the fact that both new() and 
allocation of stack frames put illegal pointer values into memory
that was allocated.

Garbage collection would be easy in Pascal except for variant records.
You know the stack frame format for each procedure and each record,
so you can find all the live pointers in a program (except in
records with variant cases).  

Of course, all this could be turned off by linking with a different
library, so "efficient" programs could be tested and then sped up.
                -- Darren