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(