Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 Adelie 8/14/85; site adelie.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!adelie!jak From: jak@adelie.UUCP (Jeff Kresch) Newsgroups: net.lang.c Subject: Re: RE: if(p) Message-ID: <500@adelie.UUCP> Date: Fri, 18-Oct-85 14:21:33 EDT Article-I.D.: adelie.500 Posted: Fri Oct 18 14:21:33 1985 Date-Received: Sun, 20-Oct-85 04:32:09 EDT References: <1671@brl-tgr.UUCP> <30000017@ISM780.UUCP> <292@graffiti.UUCP> Organization: Adelie Corporation, Newtonville MA Lines: 44 > Re: Marv Rubenstein's message. > > int i; > foo *p; > > i=0; > if(p==i)... > > What's wrong with this? It's identical to "if(p==(foo *)i)" according to the > default expression evaluation rules. Any special meaning of 0 should be > handled in the evaluation of (foo *)i. We seem to be going around in circles with this one. First, it is stated clearly in K&R that the only integer that may be compared with a pointer is the *constant* zero. (foo *)i is not a constant. Any other comparisons between integers and pointers is machine dependent, regardless of whether the integer is casted correctly or not. The reasons for this rule are not hard to understand from the point of view of implementing a compiler producing efficient code. Checking for the constant zero can be done at compile-time. The compiler just has to substitute a different value if one is required. Checking for a variable containing the value zero would require that the compiler put in extra code to do this at run time. This *code* (not the compiler) would have to check the value of the variable, and if it was zero, substitute the proper null value in the comparison, if need be. Looking at it from this perspective, it is easy to see why if (p) is reasonable. This is always taken to mean if (p != 0) and can be detected at compile-time. The compiler can substitute the appropriate value if it is required. They call me JAK