Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!decwrl!labrea!rutgers!mailrus!uflorida!haven!mimsy!chris From: chris@mimsy.UUCP (Chris Torek) Newsgroups: comp.lang.c Subject: Re: non-zero NULL pointers (oh nooooo!) (was: Re: retiring gets(3)) Message-ID: <14639@mimsy.UUCP> Date: 19 Nov 88 16:47:39 GMT References: <1988Nov8.054845.23998@utstat.uucp> <7963@bloom-beacon.MIT.EDU> <8058@bloom-beacon.MIT.EDU> Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742 Lines: 47 In article <8058@bloom-beacon.MIT.EDU> scs@athena.mit.edu (Steve Summit) writes: >The fact that the null pointer constant in C is "0" does not, >repeat not, place any restrictions on the bit pattern used by the >generated code. Using "0," rather than some machine-dependent >value, increases portability: the translation to the machine- >dependent value is made by the compiler, along with all >of the other machine-dependent translations. (Sadly, the use of >0 as the null pointer constant has increased programmer confusion >more than it has decreased machine dependencies.) Right. One way to perhaps clear up some of the confusion is to think of it this way: If C had had a `nil' keyword, one would not write char *p = 0; but rather char *p = nil; /* almost like `var p: ^char; begin p := nil;' :-) */ Now, if we had this keyword, we could also write: int execl(char *prog, char *av0, ...); and a call like execl("foo", nil); would know to cast the `nil' into a `char *' (which might very well produce the binary value `-1'), while the call execl("foo", "foo", nil); could correctly complain that it has no idea what *kind* of nil to provide. But C does not have the `nil' keyword; instead, it has `0'. When the compiler sees `0', it asks whether the `0' is filling in for `nil'. If so, it provides the appropriate cast. If it cannot tell, it *assumes* that the 0 is really a 0! The moral? Put in the cast. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris