[TUHS] reviving a bit of WWB

[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. 

I've worked on systems where a 0 pointer could be dereferenced without a trap. I wouldn't recommend it. System designers do things like make the first page of memory invalid so we will get a null pointer trap. On Plan 9 the beginning of the text segment starts at 0x1020.

But that's not part of the C language. The fact that 0 is a null pointer is.

Brantley

> On Sep 20, 2020, at 4:58 PM, Steve Nickolas <usotsuki at buric.co> wrote:
> 
> On Sun, 20 Sep 2020, Doug McIlroy wrote:
> 
>>> (Of course, that assumes NULL is 0, but I don't think I've run into any
>>> architecture so braindead as to not have NULL=0.)
>> 
>> It has nothing to do with machine architecture. The C standard
>> says 0 coerces to the null pointer. NULL, defined in <stddef.h>,
>> is part of the library, not the language. I always use 0,
>> because NULL is a frill.
>> 
>> Doug
> 
> I was under the impression that there was explicitly no requirement that a null pointer be 0, and that there was at least one weird system where that wasn't true - that it just so happened that null points to 0 on certain CPUs and that 0=NULL *happens* to work on most CPUs but wasn't guaranteed. (In fact, I read that my habit of using 0 for NULL relied on a faulty assumption!)
> 
> I mean, I've never actually used a CPU/OS/compiler where it wasn't true, but...
> 
> -uso.