Path: utzoo!attcan!uunet!dino!uxc.cso.uiuc.edu!uxc.cso.uiuc.edu!m.cs.uiuc.edu!kenny
From: kenny@m.cs.uiuc.edu
Newsgroups: comp.lang.c
Subject: Re: Uninitialized externals and statics
Message-ID: <4700042@m.cs.uiuc.edu>
Date: 24 Aug 89 23:22:36 GMT
References: <2128@infmx.UUCP>
Lines: 39
Nf-ID: #R:infmx.UUCP:2128:m.cs.uiuc.edu:4700042:000:1433
Nf-From: m.cs.uiuc.edu!kenny    Aug 24 12:14:00 1989


>On a Prime 50-series machine the representation of a NULL pointer
>is not all zeroes!

>As far as I know, however, this does not cause a problem in such
>initializations. It is appropriate when testing a pointer against
>for being the null pointer to do a case, thusly:

>      char * foo;

>      if (foo == (char *)NULL)

>but then doing such a cast is ALWAYS appropriate, on any machine, since
>right after you leave the company somebody will get the bright idea
>of porting your code to some new whiz-bang-100 processor with weird
>architecture. This is also apprpriate on 8086-class machines, since
>the representation of a pointer, including the null pointer, will vary
>with memory model. (I hate segmented architectures.)

This is BROKEN.  How many times do those of us that understand this
have to shout it?  When a pointer is compared with an integer, it is
implicitly promoted to an integer.  Saying
	if (foo == NULL)
means EXACTLY the same thing as saying
	if (foo == (char *) NULL)
and if the NULL pointer doesn't have an all-zero representation, the
compiler is responsible for promoting it.  Any compiler that doesn't
promote pointers in comparisons with integers has a serious bug.

The non-all-zero representation will break questionable code like
	struct zot {
		long zot_l;
		char *zot_p;
		} barf;

where the pointer barf.zot_p *will* be initialized to the all-zero bit
pattern.  You can't have everything.

A-T