21 Sep
2020
21 Sep
'20
3:33 a.m.
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(a)buric.co> wrote:
On Sun, 20 Sep 2020, Doug McIlroy wrote:
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.
(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