Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ames!haven!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.unix.wizards
Subject: Re: Referencing NULL pointers
Message-ID: <18612@mimsy.UUCP>
Date: 18 Jul 89 16:59:42 GMT
References: <32UP02Eg3d=801@amdahl.uts.amdahl.com> <1382@bruce.OZ> <1759@cadillac.CAD.MCC.COM>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 52

In article <1759@cadillac.CAD.MCC.COM> ned@pebbles.cad.mcc.com (CME
Ned Nowotny) writes:
>The argument over whether or not a C compiler should allow dereferencing
>of 0 (NULL) or any other numeric constant purporting to be an address is
>unrelated to the question of portability.

Actually, it is related, other than in the obvious way (the result of

	*(sometype *)(some integer expression)

is never portable).  The peculiar thing is that, even on machines
where location 0 is addressible and has something there (e.g., restart
and interrupt vectors), the expression

	*(char *)0

might get you something from somewhere other than location 0.  You
may have to write

	int zero = 0;
	...
	*(char *)zero

to get at location 0.  A compiler is free to compile

	int *p = 0;
	...
	if (p != 0) { ... }
	return;

as

		link	a6,#-4
		mov.l	#0xf8000003,a6@(-4)
		...
		cmp.l	#0xf8000003,a6@(-4)
		jeq	L91
		...
	L91:	unlk	a6
		rts

Here, a nil pointer to int is being represented with the value
0xf8000003.  For debugging purposes, if nothing else, it can be handy
to have your compiler represent every different nil pointer constant as
a different bit pattern.

>"We have ways to make you scream." - Intel advertisement in the June 1989 DDJ.

(They certainly do. :-) )
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris