Uninitialized externals and statics

kenny at m.cs.uiuc.edu kenny at m.cs.uiuc.edu
Fri Aug 25 09:22:36 AEST 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



More information about the Comp.lang.c mailing list