21 Sep
2020
21 Sep
'20
3:35 a.m.
When 0 is coerced implicitly or explicitly to a pointer type, it becomes a
null pointer. That's true even on architectures where all-bits-zero is
*not* a null pointer. However, in contexts where there is no expected
type, as in a call to execl(), the null at the end of the args list has to
be explicitly cast to (char *)0 or some other null pointer.
As for the definition of NULL, it is indeed 0 on Linux, but can also be
defined as ((void *)0), as on FreeBSD and the Mac, or even as 0L on systems
where ints are half-size and pointers and longs are full-size.
On Sun, Sep 20, 2020 at 4:59 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