Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site umcp-cs.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!umcp-cs!chris
From: chris@umcp-cs.UUCP (Chris Torek)
Newsgroups: net.lang.c
Subject: Re: RE: if(p)
Message-ID: <1899@umcp-cs.UUCP>
Date: Thu, 17-Oct-85 20:23:53 EDT
Article-I.D.: umcp-cs.1899
Posted: Thu Oct 17 20:23:53 1985
Date-Received: Sat, 19-Oct-85 07:22:34 EDT
References: <1671@brl-tgr.UUCP> <30000017@ISM780.UUCP> <484@smeagol.UUCP>
Organization: U of Maryland, Computer Science Dept., College Park, MD
Lines: 31

> From: ross@smeagol.UUCP (Gary_Ross)

> As I understand it, the C compiler interprets pointers as integers
> in terms of evaluating an if statement.

Your C compiler does, and mine does; but `the' C compiler does not.

> This means that if the value of a pointer is null, the result of:
>			if (p) statement1
>			else statement2
> will execute statement2

Correct.

> because a null pointer has value 0.

Wrong.  Not because a null pointer has the integer value zero, but
because the C language requires this.  On a sufficiently bizarre
machine, the null pointer might be represented by the double-precision
floating-point value 1.179e+7001; yet on such a machine, if the
compiler is correct, and the value of a pointer `p' is nil---compares
equal to zero, so that `(p == 0)' is true---then `if (p) s1; else
s2;' will execute s2.

Of course, most if not all current architectures do indeed represent
a null pointer with 0 or 0L; this makes code generation simpler.
But it is not required.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@mimsy.umd.edu