Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84 SMI; site sun.uucp Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!cmcl2!philabs!prls!amdimage!amdcad!decwrl!sun!guy From: guy@sun.uucp (Guy Harris) Newsgroups: net.lang.c Subject: Re: if (p), where p is a pointer - PLEASE READ Message-ID: <2807@sun.uucp> Date: Thu, 19-Sep-85 02:05:02 EDT Article-I.D.: sun.2807 Posted: Thu Sep 19 02:05:02 1985 Date-Received: Sun, 22-Sep-85 06:36:57 EDT References: <118@mit-hector.UUCP> <2792@sun.uucp> <693@sfmag.UUCP> <2798@sun.uucp> <701@sfmag.UUCP> Organization: Sun Microsystems, Inc. Lines: 56 > Well, now we come to the can of worms which causes some implementations to > #define NULL (char *) 0: machines where pointers occupy more space than > ints. Unfortunately, #defining NULL as (char *)0 will provoke more "lint" messages, which is not what is wanted here. If you're going to make "typical" code work on those machines (I spent a fair bit of time doing exactly that at CCI, along with some code - like "sdb" - which, if it's typical, means we're all in deep trouble; but I digress) you have to run it through "lint" to catch all the pointer-valued functions which aren't so declared. > Same comment as above. The solution may be that NULL should be 0L (but what > about the venerable old PDP-11? In that case, foo(NULL) passes too much > stuff on the stack. So, what is *the* answer?).... In that case, you could have different definitions of NULL for different machines. But what about a hypothetical machine (which is, I suspect, not so hypothetical) with 64K 16-bit words in a process' address space and a special two-word format for byte pointers? In that case, (int *)NULL would be 16 bits but (char *)NULL would be 32 bits. *The* answer is to cast each NULL/0 yourself, or wait for ANSI C and have it do the coercions for you (which doesn't help with existing code). In retrospect, perhaps C should have had a keyword like "nil" to represent null pointers. 1) Assignments of the sort pointer_variable =; would no longer have different meanings depending on whether the was a constant 0 or not. 2) The confusion that has sprung up between null pointers and pointers filled with 0 bits - and the subsequent confusion indicated by people thinking NULL should *really* be defined as a constant with the same bit pattern as a null pointer on a particular machine - might have been avoided. 3) If the rules for "nil" were that a) a naked "nil" is illegal but b) as the operand of an operator whose other operand or result were of a particular pointer type, a "nil" becomes a null pointer of that type, code like setbuf(stdout, nil); would be illegal (no such operator nearby) and the "nil" would have to be properly cast. "int *p; p = nil;" would compile properly, as the "nil" is an operand of the "=" whose other operand is a "pointer to int". However, hindsight is 20/20; if C had everything in it that it "should" have had, it might be a better language but its compiler might not have fit on the PDP-11... Guy Harris