Frank Heckenbach wrote:
I'm considering adding runtime checks for nil pointer access. The benefits are not as big as one might suppose, since most systems catch a nil pointer access anyway and give a segmentation fault automatically. Whereas explicit runtime checks might add considerable runtime overhead. Additionally, some valid (well, let's at least say, working) BP and similar programs might fail then, e.g. if they pass dereferenced pointers (which may be nil) as var parameters, and the called routine either doesn't access the parameter or explicitly checks if it's address is nil.
On the positive side, such a check might provide a somewhat nicer error message (proper runtime error instead of segfault), and it can be caught like other runtime errors (e.g. via `AtExit') rather than with a signal handler as for segfaults. Also, strict standard conformance makes it an error, even in a situation as described above where the var parameter is never used.
Since Pascal does not bandy pointers about, pointer checks can be quite accurate. However they have to be customized to the actual package. For example, using my nmalloc package for DJGPP agreement between a couple of internal linkages, and absence of the 'freed' marker, suffice. On an ancient CP/M system the check consisted of ensuring that the pointer lay within the current heap region, or (for thoroughness) following a linked list for membership. None of this applies to another installation. Once you have such a NIL check is trivially added, the only need being to control energization. If the pointer check is done during pointer variable assignment, it can be omitted during dereference, and the only dereference need is for NIL, and the NIL check is not needed during the assignment check.
It should be possible to turn this on and off by pseudo comments. Without this any creation of C style pointers will become impossible.