Re: using literal zero for NULL

["Alan M. Evans" <ame1 extratech com>]

On Wed, 2006-03-22 at 00:48, Paul LeoNerd Evans wrote:
> On Mon, Mar 20, 2006 at 11:53:35PM -0800, mikecorn wrote:
> > I just tried rebuilding my GTK apps for a 64 bit Linux system (Fedora core
> > 5), and had an ugly surprise: random segmentation faults. I traced at least
> > one of them to my lazy habit of using a literal zero in place of NULL for an
> > optional function argument or end-of-arg-list indicator. I speculate that
> > the compiler is supplying a 32 bit zero where a 64 bit zero is needed.
> > Correct? If so, it seems this is a compiler bug, since the type conversion
> > should be automatic. Can someone confirm this?
> 
> Sounds about right. I hit this issue a lot trying to build tla on AMD64.
> 
> I find, as well as keeping the compiler happy, using the right named
> constants is good for readability. Consider the following three lines:
> 
>   foo(FALSE);
>   bar(0);
>   baz(NULL);
> 
> Their argument might compile to the same value each time; but to the
> reader, each gives a different impression as to its meaning. The first
> is a boolean negative value; you might expect to see foo(TRUE) somewhere
> else. The second is the numerical concept of zero; you might expect to
> see a different number elsewhere, e.g. bar(10). The third is a pointer
> which currently points at nothing but might some other times point at
> some valid object.
> 
> I've never worked out why anybody needs to type "0" when they could type
> "NULL". Given all the random segfaults, and type errors, and readability
> concerns and whatnot, are your fingers _really_ that lazy?

I'd say it's more a matter of taste. And your argument is mostly
stylistic. Tastes differ.

In fact, an unadorned zero works perfectly well in all cases except
unprototyped function parameters. (This thread started with the error of
passing zero in varargs, which are technically unprototyped even when
the function is prototyped.)