Xref: utzoo comp.arch:4874 comp.lang.c:10200
Path: utzoo!attcan!uunet!husc6!bloom-beacon!mcgill-vision!mouse
From: mouse@mcgill-vision.UUCP (der Mouse)
Newsgroups: comp.arch,comp.lang.c
Subject: Re: negative addresses
Message-ID: <1115@mcgill-vision.UUCP>
Date: 18 May 88 08:29:58 GMT
References: <2393@uvacs.CS.VIRGINIA.EDU> <21541@amdcad.AMD.COM> <10001@tekecs.TEK.COM>
Organization: McGill University, Montreal
Lines: 32
Posted: Wed May 18 04:29:58 1988

In article <10001@tekecs.TEK.COM>, andrew@frip.gwd.tek.com (Andrew Klossner) writes:
> Doug Gwyn (gwyn@brl-smoke.ARPA) writes:
[an attribution appears to have been lost, but presumably it's our
friend Andrew Klossner]
>>> 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):
> 		if (tbuf->c_ptr)
> 		if (tbuf->c_ptr == NULL)
> 		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.

But when a pointer is compared against the integer constant zero,
either explicitly (second example) or implicitly (other three
examples), the zero is cast to the appropriate pointer type, producing
whatever bit pattern is appropriate for a null pointer of that type.
(Similar things happen when assigning the integer constant zero to a
pointer.  Note that "integer constant zero" is not the same thing as
"integer expression with value zero".)  This was true in K&R and
remains true in the dpANS.

					der Mouse

			uucp: mouse@mcgill-vision.uucp
			arpa: mouse@larry.mcrcim.mcgill.edu