Re: [TUHS] reviving a bit of WWB

[norman@oclsc.org (Norman Wilson)]

Brantley Coile:

  The fact that a pointer of zero generates a hardware trap is not
  defined in the language, whereas a 0 is is defined to be a null pointer.

=====

The language doesn't require that dereferencing a null pointer
cause a trap, either.  There's no way to guarantee that behaviour
in all environments unless every pointer dereference must include
instructions to check for the null-pointer value, because C can
run in environments in which any pointer value might be a valid
address.

On modern machines it's conventional for the null-pointer value
in C, what you get when you assign 0 to a pointer, to be all-zeroes;
and for operating systems to arrange that that address is unmapped.
But that wasn't always so (on the PDP-7 there was no memory map;
on the PDP-11 once memory-mapping was added, address space was
too dear to throw away an eighth of it just to block null-pointer
dereferencing), and it may still not be (consider a C program
on an embedded system running without a memory map).

It's good that modern systems usually whap you in the head if you
deference a null pointer, but it's not required, and those who
rely on it are as foolish as those who used to rely on the
accident that the byte at address 0 on early VAX UNIX was a zero.

Norman Wilson
p&p6 and f(