"Frank D. Engel, Jr." wrote:
My point here was to use the reference counts to track dangling pointers. Once the number of dangling pointers reaches zero, there aren't any anymore; meanwhile, checking that count before accessing the memory location would provide instant and very efficient confirmation on whether or not the pointer is still valid.
Please don't top-post.
Reference counting won't help without a complete handle system to process all accesses indirectly. This won't mesh very will with usage for VAR parameters.
The problem appears when an extra copy of a pointer has been made and the original freed or disposed. It is easy to mark the original NIL at this time. But with most implementations the copy is left pointing to somewhere within the heap. Later in the codes life that somewhere may have become somewhere within a completely unrelated object, which happened to reuse the memory that was freed. At this point there is no way to check anything about that original copy pointer, whatever is lying about the pointed location is random to it.
That is why nmalloc checks for some relationships that should apply. At some negative displacement should be a pointer to another block, which in turn should contain a pointer back. There should be another specific value marking this block as non-free. These CAN be satisfied by random data, but probably won't be.
The question is how much overhead to put on pointer dereference. In Pascal, unlike C, we can tell such from VAR dereference through the type system. There is a non-trivial problem involved in passing that knowledge through functional parameters. This can be handled by performing the check at the point of passage, and thenceforce treating as a VAR. Any such mechanism as outlined above depends on intimate knowledge of the actual heap allocation mechanism, and involves overhead. VAR dereference is generated directly by the compiler, and known correct (what is not necessarily known is the validity of an offset, or index, value).