[TUHS] reviving a bit of WWB

[John Cowan]

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 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200920/4988318a/attachment.htm>