Path: utzoo!dciem!nrcaer!sce!cognos!jimp From: jimp@cognos.UUCP (Jim Patterson) Newsgroups: comp.std.c Subject: Re: all bits zero? Message-ID: <8139@cognos.UUCP> Date: 3 Apr 90 13:37:14 GMT References: <2108@gmdzi.UUCP> <12570051@hpclscu.HP.COM> Reply-To: jimp@cognos.UUCP (Jim Patterson) Organization: Cognos Inc., Ottawa, Canada Lines: 38 In article <12570051@hpclscu.HP.COM> shankar@hpclscu.HP.COM (Shankar Unni) writes: >> how many machines exist where the following does not hold. >> >> char*, struct FOO* NULL is represented as binary zeros > >I know of at least one (albeit only by software convention): on the classic >HP3000's (16-bit stack machines), a pointer with all-zeros is a perfectly >valid address On the "classic" HP 3000 though, there is no "invalid" address. Using 0 for NULL is as good as any choice; all that the compiler-system has to do to ensure that this is legal is reserve the first word of the address space (i.e. make sure that no "valid" object ever goes there). Putting a string literal "(nil)" there might be nice (it causes printf() to do nice things with NULL pointers, like the old PDP-11 compilers, apparently). Note that the ANSI definition of a null pointer constant states simply that it cannot point to any valid object. So long as the compiler never allocates data at that address (either static or auto), and so long as the memory allocation subsystem malloc et. al. don't (except perhaps for size 0 objects), then this constraint is satisfied. In fact, the compiler need not actually prevent dereferencing of "null"; the behaviour is undefined according to the standard. >I must admit, however, that the C compiler on that machine (at least, the >one that I am familiar with - the CCS C/3000 compiler) leaves NULL as >"all-zeroes", No doubt a wise choice given the immense amount of "prior art" regarding NULL and 0. -- Jim Patterson Cognos Incorporated UUCP:decvax!utzoo!dciem!nrcaer!cognos!jimp P.O. BOX 9707 PHONE:(613)738-1440 3755 Riverside Drive Ottawa, Ont K1G 3Z4