Frank Heckenbach wrote:
... snip ...
IMHO dangling pointers are the more serious problem, since wild pointers (outside the heap) area can be avoided, e.g. by initializing all pointers to nil (though I don't recommend to do this always) and not doing other dirty stuff, while dangling pointers are more difficult to avoid "statically".
Your linked list suggestion would detect them (simple heap bounds checking would not). But it adds an O(n) factor in each pointer access which is often not acceptable. I'm not aware of other methods which don't either also add some runtime overhead (though one might get it down to O(ln n) by using a good data structure, perhaps a balanced tree) or produce a memory leak (such as by keeping track of all disposed pointers).
That is only one method. I don't know if gpc depends on the underlying c malloc/free/realloc package, but if so that package should be replaceable (in many cases) with my nmalloc for djgpp. That depends on alignment size, 32 bits, byte ptr to void * conversions for arithmetic, and getting memory via sbrk. Given that the pointer validity tests become O(1). They are not guaranteed to catch everything, but the odds are high.
You can look it over at:
http://cbfalconer.home.att.net/download/nmalloc.zip
My other point is that most of the pointer checks are done when passing or storing the pointer in the first place, not while dereferencing it. Pointers that the compiler/runtime makes for VAR params etc. are known valid, provided any indexes off them are properly checked. Heap pointers come from something checked at creation, so the only worries should be dereferencing NIL and stale pointers. NIL is a fixed bit pattern. The nmalloc techniques can detect most of the stale items. They only get exercized during free or realloc.