Path: utzoo!attcan!uunet!wuarchive!udel!new From: new@udel.edu (Darren New) Newsgroups: comp.lang.misc Subject: Re: Relationship between C and C++ Message-ID: <14804@nigel.udel.EDU> Date: 23 Mar 90 18:41:43 GMT References: <8432@hubcap.clemson.edu> <5200048@m.cs.uiuc.edu> <4869@vanuata.cs.glasgow.ac.uk> <1990Mar22.181947.27026@maths.nott.ac.uk> Sender: usenet@udel.EDU Reply-To: new@udel.edu (Darren New) Organization: University of Delaware Lines: 41 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