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.
Therefore, perhaps, the check should be off by default, and on only in standard modes, and of course, triggered by its own new option (`--[no-]pointer-checking'?).
Another runtime check (which BTW should also be rather easy to implement now), is for objects, whether they point to a valid VMT, using the `NegatedSize' VMT field, just like BP does. AFAIR, BP does it on virtual method calls, where the VMT is used. In principle, the check could be done on every object operation/access, but that might be overkill.
Since a simple check per virtual method call is not much overhead, I propose the check to be on by default, in all dialects. Of course, it will also get its own option (`--[no-]object-checking'?).
BP couples it to range-checking (I can only guess why -- perhaps because they only have short, i.e. one-letter, compiler directives, and they wanted to save a letter). For strict compatibility, we could add a combined option (`--[no-]range-and-object-checking'), and make `{$R[+-]}' equivalent to that.
Frank