Path: utzoo!attcan!uunet!snorkelwacker!ai-lab!bson
From: bson@wheaties.ai.mit.edu (Jan Brittenson)
Newsgroups: comp.unix.wizards
Subject: Re: What machines core dump on deref of NULL?
Message-ID: <9361@rice-chex.ai.mit.edu>
Date: 6 Jul 90 23:01:02 GMT
References: <13226@smoke.BRL.MIL> <1990Jun29.132304.12550@athena.mit.edu> <418@minya.UUCP> <1990Jul6.152722.5320@eng.umd.edu>
Reply-To: bson@rice-chex.ai.mit.edu (Jan Brittenson)
Organization: MIT Artificial Intelligence Laboratory
Lines: 49

In article <1990Jul6.152722.5320@eng.umd.edu>
russotto@eng.umd.edu (Matthew T. Russotto) writes:

>In article <418@minya.UUCP> jc@minya.UUCP (John Chambers) writes:

>>And on page 192 of my C bible I find the paragraph:
>>	[...] it is guaranteed that assignment of
>>	the constant 0 to a pointer will produce a null pointer distinguish-
>>	able from a pointer to any object.
>>

>Distinguishable in this sense just means you can use tests like
>
>p=0;
>if (p == &someobject)
>	code();
>else
>	othercode()
>
>which will always fail

   Not if someobject resides at address 0, in which case p does point
to an object. In addition, the address calculation &someobject might
yield a pointer to address 0. E.g.,

		char foo[1];
		... &foo[ -(int) &foo ] ...

   Even when limiting ourselves to unix and the more common
implementations can we come up with a reason for treating (char *) 0
as a specific object; to probe the access rights of ones u area, for
instance. But for compatibility's sake NULL should be treated as "a
pointer not pointing at any object" - esp. when the intention is to
later be able to port software from the unix environment to a non-unix
environment where variables may very well be located at 0.


> (it probably also means that malloc, etc, can never
> allocate an object at 0)

   If malloc() returns NULL, that should be regarded as "no object
allocated." In future implementations 0 may be the first location of
an upwards-growing heap for all we know... Of course the problem could
be easily avoided by never using address 0, but that's - as far as I
can tell - exactly what John Chambers argued against in the first
place. To summarize, I think John's argument is quite valid, although
I think the problem can be easily dodged at the cost of grace.

(Disflamer: all above is IMHO.)