Path: utzoo!attcan!uunet!husc6!mailrus!nrl-cmf!ames!umd5!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: negative addresses
Message-ID: <7917@brl-smoke.ARPA>
Date: 18 May 88 14:36:26 GMT
References: <10001@tekecs.TEK.COM> <2393@uvacs.CS.VIRGINIA.EDU> <21541@amdcad.AMD.COM> <1988May12.162906.16901@utzoo.uucp> <7881@brl-smoke.ARPA> <3504@pasteur.Berkeley.Edu>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 18

In article <3504@pasteur.Berkeley.Edu> faustus@ic.Berkeley.EDU (Wayne A. Christopher) writes:
>In article <10001@tekecs.TEK.COM>, andrew@frip.gwd.tek.com (Andrew Klossner) writes:
>> 		if (tbuf->c_ptr)
>The trick here is that whenever a pointer is converted into an
>integer (as here), the NULL pointer must be converted to the integer
>0.  It doesn't matter what the bit pattern is before conversion.

You got the right answer by the wrong reasoning.
The pointer is NOT converted to an integer.
This partial-statement is fully equivalent to
	if (tbuf->c_ptr != 0)
and the integer constant 0 is guaranteed to
be comparable to a null pointer.  How this is
accomplished is the implementor's business,
and does NOT imply that a null pointer of a
given type (there are different pointer types!)
is represented in a way that "looks like" the
representation of integer value 0.