Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1a 12/4/83; site rlgvax.UUCP Path: utzoo!watmath!clyde!floyd!harpo!seismo!rlgvax!guy From: guy@rlgvax.UUCP (Guy Harris) Newsgroups: net.unix-wizards Subject: Re: Please use NULL instead of 0 whenever you have a pointer! Message-ID: <1651@rlgvax.UUCP> Date: Fri, 3-Feb-84 17:50:09 EST Article-I.D.: rlgvax.1651 Posted: Fri Feb 3 17:50:09 1984 Date-Received: Thu, 9-Feb-84 06:44:20 EST References: <16022@sri-arpa.UUCP> <3811@genrad.UUCP> Organization: CCI Office Systems Group, Reston, VA Lines: 58 > After hearing all the controversy that NULL is identically equal to zero, > the only sane solution is to fix the C language. Add a special constant > that is the equivalent of zero, but is a pointer. Since NULL already has > bad connotations, let's borrow from PASCAL, and call it NIL. > Now NIL is guaranteed to be a pointer of the largest type (char * ?) but > it will compare against any pointer without error and it can be passed > as a subroutine argument. NIL can be assigned to any pointer type, and > will always be guaranteed to be different than a valid pointer. > It would be nice if the definition of NIL included the restriction that > a dereference of NIL would always cause a run-time error, but maybe this > is too much to ask for. > Those of us without the "fixed" compiler can #define NIL ((char *) 0) > and use it anyway (although some of the compilers may complain about > "illegal pointer combination"s) Well, #define NIL ((char *)0) will do exactly what the NIL you mention does. EITHER ONE will cause compilers to complain - CORRECTLY - about illegal pointer combinations. There is no such thing as a "generic pointer" in C. Period. As such, there is no such thing as a generic null pointer in C. Period. It may be awkward on non-byte-addressed machines to implement (char *) and (int *) (or (anything else *)) so that (char *)&foo and (int *)&foo yield the same bit pattern. Furthermore, it is not necessary, as a correct C implementation will generate code to do the pointer format conversion if one assigns an (int *) to a (char *), or vice versa - with ONE exception: since there is no way to tell a C module that a function in another C module ("module" here means "source file") takes arguments of a certain type, no C compiler can generate code to do conversion of arguments to functions automatically. You have to help the compiler here by putting in explicit casts. I read a lot of articles on this subject whose real point seems to be that it's too much trouble to properly cast 0 or NULL when passed as an argument to a function. What's so hard about it? Those of us who've worked on machines with 16-bit "int"s and 32-bit pointers do it as a matter of habit. I even did it *before* I worked on such a machine, just because the minimal extra effort to write type-correct code (yes, you *can* write code which is 99% type-correct in C) is worth the effort. The only thing C "needs" is a way to declare the types of the arguments to a function, so that the compiler can generate the casts instead of requiring the user to do so. However, one can put in the proper casts explicitly, so C *isn't broken* in this regard. People may be too lazy to use C properly, but there is a rather low limit on the degree to which things should - or even can - be designed so that people who don't know how to use them won't break them. Please, people, if you don't yet know that there aren't generic pointers in C, and therefore that there is no such thing as a generic "null pointer" in C, and furthermore that there *shouldn't* be such a beast, please go back and read the C Reference Manual - especially the sections I referred to in an earlier article. It's been explained several times here why C doesn't need to be changed to "fix" the problem with NULL pointers; please don't force it to be explained again. Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy