Path: utzoo!mnetor!uunet!husc6!mailrus!ames!umd5!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: Value of a null pointer
Message-ID: <7755@brl-smoke.ARPA>
Date: 24 Apr 88 18:41:28 GMT
References: <4728@cup.portal.com>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Distribution: na
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 33

In article <4728@cup.portal.com> Paul_L_Schauble@cup.portal.com writes:
>He cites two reasons:
>1. An uninitialized external is set to zero bits. C defines an uninitialized
>   external pointer to be a null pointer. Therefore zero bits must be a null
>   pointer.

No, an uninitialized external datum is automatically initialized with
a zero of the right type.  The representation of this zero need not be
all zero bits, and it necessarily depends on the type.

>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.
>   Therefore.......

calloc() initializes the allocated storage to zero byte (char) values.
That may or may not be suitable for interpretation as an array of
zero floating-point or null pointer values, depending on the architecture.

>    ptr_type_var = (ptr_type)0;     /* assigns null pointer */
>    ptr_type_var = 0;               /* assigns null pointer */
>    func( (ptr_type)0 );            /* function expecting pointer type */
>Are all of these always correct?

Yes, those are correct uses of null pointers.

The confusion probably arises because the following:
	0
can be used to initialize a pointer variable with a null pointer,
and it also will compare equal to a null pointer of any type.
The thing to realize is that the compiler may have to map that
apparently-integer-constant 0 into some strange internal form
when necessary to properly match the way that pointers are
represented.