Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!ncar!oddjob!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: Value of a null pointer
Message-ID: <11198@mimsy.UUCP>
Date: 24 Apr 88 11:05:46 GMT
References: <4728@cup.portal.com>
Distribution: na
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 38

In article <4728@cup.portal.com> Paul_L_Schauble@cup.portal.com writes:
>... I have a co-worker claiming that C requires that a null pointer be
>binary zero. He cites two reasons:

[both are wrong]

>1. An uninitialized external is set to zero bits.

An uninitialised external is set to `zero'.  If the external is a
pointer, it is to be set to NULL, which may not be all zero bits.  (It
is true, as far as I know, that no existing Unix system bothers to
distinguish between pointers and other data.)

>2. One can use calloc to allocate an array of pointers. The initial value of
>   this array must be null pointers. calloc sets the area to zero bits.

The first and third statements are correct; the second is not.  Or
so says the dpANS, anyway.

>Also, does the new standard require that a cast of a literal zero always
>does the right thing?

Yes.

>I believe that ... there are machines running it where the null
>pointer is non-zero. What I need, if possible, are specific citations.

I have heard of one, or perhaps two, efforts at writing compilers for
machines on which the machine's preferred nil-pointer format was not an
all zero bit pattern of some appropriate size.  The implementors ran
into so much code that assumed otherwise that they finally gave in and
did runtime conversions and tests, rather than using the hardware nil
types.

In other words, when it comes to *existing implementations*, your
co-worker is probably right.  When it comes to definitions, he is wrong.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris