Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site hocda.UUCP Path: utzoo!watmath!clyde!burl!hou3c!hocda!hom From: hom@hocda.UUCP (H.MORRIS) Newsgroups: net.lang.c Subject: Re: Is #define NULL 0L ok? Message-ID: <383@hocda.UUCP> Date: Thu, 15-Mar-84 19:49:37 EST Article-I.D.: hocda.383 Posted: Thu Mar 15 19:49:37 1984 Date-Received: Fri, 16-Mar-84 03:05:18 EST References: <6911@unc.UUCP> Organization: Bell Labs, Holmdel Lines: 20 A "real" NULL such that one can say foo(NULL) instead of foo((char *)NULL) with perfect assurance implies that while compiling the line foo(NULL) the cc knows something about the arguments declared for the function foo. That implies in turn that either cc snoops around for the file containing the declaration of foo - which gives you a language with a radically different philosophy from C, or else within the file containing `foo(NULL)' there is a declaration of the form: return-type foo( (char *)); instead of what is currently allowed: return-type foo(); (the former describes foo's arguments; the latter doesn't). I heard somewhere that this is being considered. I am not passionate about whether function definitions which describe the argument type are a good thing. I feel strongly that they should be optional so as to allow functions which take variable argument lists like printf. But just to point out that without such a construct, you can't have foo(NULL) work always on all machines when argument to foo is a pointer. Hal MOrris ...hocad!hom