Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site qubix.UUCP Path: utzoo!watmath!clyde!floyd!harpo!decvax!decwrl!sun!qubix!msc From: msc@qubix.UUCP (Mark Callow) Newsgroups: net.lang.c Subject: Re: Is #define NULL 0L ok? Message-ID: <925@qubix.UUCP> Date: Tue, 13-Mar-84 20:31:40 EST Article-I.D.: qubix.925 Posted: Tue Mar 13 20:31:40 1984 Date-Received: Thu, 15-Mar-84 00:34:16 EST References: <4072@edai.UUCP> Organization: Qubix Graphic Systems, Saratoga, CA Lines: 32 The situation as succintly as I can put it is: 1) The C language definition (K&R) says that the *symbol* '0' may be used to represent a null pointer. 2) The compiler therefore has to identify places where '0' is being used as a null pointer (for example by identfying assignments to or comparisons with pointers) and it has to *replace it with* the actual value of a null pointer for the particular machine and the data type being pointed to. 3) Given that there is no requirement (and no way) to inform the compiler of the types (or number) of arguments to an external function the compiler can't know that some argument to your function is a pointer. In the case of func( 0 ); therefore, the compiler can't intuit whether '0' is being used as a null pointer or in its more common usage as the symbol for the arithmetic value 0. 4) The compiler assumes the more common usage so if the argument to *func* is actually a pointer you *must* give an explicit cast to the correct type of pointer. For example you must say func( (char *)0 ); -- From the Tardis of Mark Callow msc@qubix.UUCP, decwrl!qubix!msc@Berkeley.ARPA ...{decvax,ucbvax,ihnp4}!decwrl!qubix!msc, ...{ittvax,amd70}!qubix!msc