Xref: utzoo comp.arch:4879 comp.lang.c:10208
Path: utzoo!attcan!uunet!husc6!mailrus!nrl-cmf!ames!amdcad!tim
From: tim@amdcad.AMD.COM (Tim Olson)
Newsgroups: comp.arch,comp.lang.c
Subject: Re: negative addresses
Message-ID: <21670@amdcad.AMD.COM>
Date: 18 May 88 15:48:14 GMT
References: <2393@uvacs.CS.VIRGINIA.EDU> <21541@amdcad.AMD.COM> <1988May12.162906.16901@utzoo.uucp> <7881@brl-smoke.ARPA> <10001@tekecs.TEK.COM>
Reply-To: tim@amdcad.UUCP (Tim Olson)
Organization: Advanced Micro Devices
Lines: 43

In article <10001@tekecs.TEK.COM> andrew@frip.gwd.tek.com (Andrew Klossner) writes:
| Doug Gwyn (gwyn@brl-smoke.ARPA) writes:
| 
| >> Unfortunately, it is a real problem, because there are zillions of
| >> programs that implicitly assume that [null] pointers are all-zeros.
| 
| > I don't think this is true.  How about an example?
| 
| Sure Doug, from the system V kernel that you defend so ardently :-),
| file io/tt1.c (vanilla release 3.1):
| 
| In routine ttout:
| 
| 		if (tbuf->c_ptr)
| 
| appears twice.  (And in the same routine,
| 
| 		if (tbuf->c_ptr == NULL)
| 
| appears twice.  Multiple hackers have clogged through here.)
| 
| In routine ttioctl:
| 
| 		if (tp->t_rbuf.c_ptr) {
| 		if (tp->t_tbuf.c_ptr) {
| 
| The C standards I've seen so far are pretty clear in stating that the
| conditional is compared against zero.  There doesn't seem to be leeway
| to define pointer comparisons to be against some non-zero NULL value.

"NULL" wasn't being discussed, it was the internal representation of null
pointers (this seems to cause so much confusion -- how about calling the
latter a different name, like "nil"?).

As has been stated in comp.lang.c numerous times: in C, nil can be any
bit pattern, as long as it is guaranteed not to ever point to valid
data.  NULL must be 0 (or perhaps (void *)0 under ANSI).  The compiler
takes care of the appropriate conversions between NULL and nil.  The
above code is correct C.

	-- Tim Olson
	Advanced Micro Devices
	(tim@amdcad.amd.com)