Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!rutgers!att!dptg!ulysses!andante!alice!ark
From: ark@alice.UUCP (Andrew Koenig)
Newsgroups: comp.lang.c
Subject: Re: What C compilers have non-zero null pointers?
Message-ID: <11064@alice.UUCP>
Date: 18 Jul 90 17:54:54 GMT
References: <GMKM5FY@drivax.UUCP> <9007161750.AA00664@edison.CHO.GE.COM> <12288@netcom.UUCP>
Organization: AT&T Bell Laboratories, Liberty Corner NJ
Lines: 36

In article <12288@netcom.UUCP>, ergo@netcom.UUCP (Isaac Rabinovitch) writes:

> True.  But what the "NULL should always be 0" diehards want is not to
> write (for example)

> 	for (ptr = fist; ptr != 0; ptr = ptr->next)

> in which 0 should probably be #DEFINED anyway, but rather

> 	for (ptr = first; ptr ; ptr = ptr->next)

These two forms are guaranteed to be equivalent (if you change `fist'
to `first' in the first example).  Period.

> which produces tighter code and (most important of all) looks
> spiffier.  It has the elegance of expression old C hands crave.

Whether it produces tighter code is a matter between you and your
local implementation.  Since the two forms are equivalent, there is
no particular reason to believe that they will produce different code
at all.

> My '78 K&R says that assigning 0 to a pointer is (or was) guarranteed
> to produce a NULL, even on compilers that didn't like other
> integer-to-pointer assignments.  But, interestingly, they did *not*
> guarantee, even then, the reverse!

Yes indeed.  However, if you write

	ptr != 0

then the 0 is converted to a pointer of the appropriate type and then
compared, and that *is* guaranteed to work.
-- 
				--Andrew Koenig
				  ark@europa.att.com