Path: utzoo!attcan!uunet!wuarchive!usc!rutgers!mcnc!rti!xyzzy!larrybud.rtp.dg.com!goudreau From: goudreau@larrybud.rtp.dg.com (Bob Goudreau) Newsgroups: comp.lang.c Subject: Re: references to dereferenced null pointers Message-ID: <1531@xyzzy.UUCP> Date: 16 Mar 90 01:57:44 GMT References: <945@ns-mx.uiowa.edu> <51083@microsoft.UUCP> <25EB8EE8.8462@paris.ics.uci.edu> <1990Mar12.175613.12082@utzoo.uucp> <1623@argus.UUCP> <1990Mar14.164539.23685@utzoo.uucp> <16179@haddock.ima.isc.com> Sender: usenet@xyzzy.UUCP Reply-To: goudreau@larrybud.rtp.dg.com (Bob Goudreau) Organization: Data General Corporation, Research Triangle Park, NC Lines: 31 In article <945@ns-mx.uiowa.edu>, williams@umaxc.weeg.uiowa.edu (Kent Williams) writes: > In article <16179@haddock.ima.isc.com> karl@haddock.ima.isc.com (Karl Heuer) writes: > >In article <1990Mar14.164539.23685@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: > >>There is absolutely nothing wrong with having a pointer representation in > >>which the bit pattern for a null pointer is not all zeros... except that > >>there are a lot of old, badly-written programs which will break. Thus my > >>earlier comment that it is valid but unwise. > > > >Note that "p = 0", "p == 0", "!p", "char *f() { return 0; }" are *not* > >examples of such badly-written code; they may be bad style, but the compiler > >is required to generate correct code involving a true null pointer. > > The bottom line in actual practice is that if NULL isn't a binary object > of all zero bits, you can get into trouble porting programs. Using 0 and > NULL interchangebly is an unfortunate but common practice -- see code > examples in Stroustroup's C++ book -- many assignments of 0 to > pointers. Sigh... Looks like it's time for Chris Torek to repost his explanation of NULL and 0.... ------------------------------------------------------------------------ Bob Goudreau +1 919 248 6231 Data General Corporation 62 Alexander Drive goudreau@dg-rtp.dg.com Research Triangle Park, NC 27709 ...!mcnc!rti!xyzzy!goudreau USA