Re: using literal zero for NULL



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?

-- 
Paul "LeoNerd" Evans

leonerd leonerd org uk
ICQ# 4135350       |  Registered Linux# 179460
http://www.leonerd.org.uk/

Attachment: signature.asc
Description: Digital signature



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]