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