CBFalconer wrote:
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.
Yes, it can be replaced this way. (It can also be replaced on the Pascal level, see GetMemPtr in module GPC, but since this wouldn't affect, e.g., C libraries used in the program, including libc, which do memory allocation themselves, replacing malloc etc. on the linker level actually seems better here.)
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.
I think it's dangerous to talk about "odds" here. It all depends on the use, doesn't it? A program which never frees any memory, obviously has smaller odds of such failure than a program which frequently allocates and frees memory (in particular, if it always of the same size, as it is in lists).
If you're willing to accept such "odds" in certain programs, you can do this, of course. That's why I suggested a user-routine for pointer validity checking.
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.
Which means that we do need this check at dereferencing time (as they may become stale between assignment and dereferencing).
Frank