Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ukma!xanth!kremer
From: kremer@cs.odu.edu (Lloyd Kremer)
Newsgroups: comp.lang.c
Subject: Re: calloc (actually NULL =?= 0)
Summary: further clarification
Message-ID: <8443@xanth.cs.odu.edu>
Date: 13 Apr 89 13:33:50 GMT
References: <22842@shemp.CS.UCLA.EDU> <1428@auspex.auspex.com> <987@atanasoff.cs.iastate.edu>
Distribution: na
Organization: Old Dominion University, Norfolk, Va.
Lines: 40



[In response to the hypothesis that a NULL pointer must consist of zero bits]

In article <1428@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes:
>Nope.  No such guarantee was ever made by any C language spec.

In article <987@atanasoff.cs.iastate.edu> hascall@atanasoff.cs.iastate.edu (John Hascall) then responds:
>   What about the following taken from K&R, Appendix A, section 7.14,
>   "Assignment operator":
>
>       [talking about assigning ints to/from pointers
>       being "a bad thing"] ...
>       However, it is guaranteed that assignment of the
>       constant 0 to a pointer will produce a null pointer...


There is really no contradiction in any of this.  The whole issue of what bit
pattern is used to represent various objects is on a lower plane than a
discussion of any C Language specification.

There could be some weird system that chooses (speaking in hex) to represent
the integer zero as 7FFF, and to represent the nil pointer (a pointer
guaranteed not to point to any valid object) as FF00.  The C Language
specifications, including the K&R reference cited above, merely state that
even in such an implementation, the common C language constructs

	if (ptr == 0)
or
	if (!ptr)

**MUST STILL WORK AS EXPECTED**, even if the compiler writers have to do
assembly language gymnastics to make it work.


					Hope this helps,

					Lloyd Kremer
					Brooks Financial Systems
					{uunet,sun,...}!xanth!brooks!lloyd