Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!dcl-cs!aber-cs!rupert!pcg From: pcg@rupert.cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.lang.c++ Subject: Re: references to dereferenced null pointers, etc... Message-ID: Date: 14 Mar 90 08:55:21 GMT References: <51083@microsoft.UUCP> <25EB8EE8.8462@paris.ics.uci.edu> <1990Mar12.175613.12082@utzoo.uucp> <1623@argus.UUCP> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 76 In-reply-to: ken@argus.UUCP's message of 13 Mar 90 20:25:47 GMT In article <1623@argus.UUCP> ken@argus.UUCP (Kenneth Ng) writes: In article <1990Mar12.175613.12082@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes: : >once thought of doing an implementation where NULL != 0, but after further : >reading convinced myself the implementation would be invalid. : Not invalid, no; I think there are one or two such. If I remember correctly, either the Pr1me or Data General C did represent the null pointer with a bit pattern that was not all 0s. I'm confused, is a non zero NULL pointer valid or not? The internal representation of a null pointer (not NULL -- 'NULL' is just a popular macro) can be anything at all, as long as it does not coincide with the representation of any valid pointer. I remember however that some past edition of the X/open guide mandated the use the NULL macro and not the constant 0, precisely to make supporting non binary 0s null pointers easier. Bah. The NULL macro can well be defined as something else then constant 0, e.g. the address of an entity that is guaranteed not used elsewhere. This is another of those K&R points that have been vastly ignored by almost everybody; contrarily to some Holy Commandament, a lot of (UCB) people assumed the world was a VAX. The null pointer issue has been debated many times in comp.lang.c; I think it is in the frequently asked questions document, and somebody (Spencer or Torek) have a writeup that discusses it to death (e.g. the fallacy of using 0L as null pointer on machines where 'sizeof (int) < sizeof (char *)'). What about C++? Well, there are some nice ways to have portable null pointers without using the constant 0, that IMNHO is not as descriptive as it should be. The first is to use #define nil(TYPE) ((TYPE) 0) and the second is to use (Algol 68 like) extern const char empty; /* Definition elsewhere */ static const char *nil = ∅ and the third is static const char *nil = 0; As to the latter, it assumes that the null pointer of type 'char *' converts to the null pointer of type 'anytype *' in the appropriate context. Well, let's hope :-). Note that is the second and third example we are using 'char *' because we are guaranteed that any pointer cast to 'char *' and back to its original type will be unchanged. This may be inefficient on some machines (e.g. Pr1me) for which 'char *' has a particular representation. Let me mention another two subtle Classic C points, that have received less attention and whose definition is different in C++ 2.0: 1) In Classic C 'sizeof (char)' was not necessarily 1. In particular, on some machines and some implementations (PDP-10 C?) 'sizeof' units were bits. This is of course very wise for certain machines that have 36 bit words and 7 bit bytes. The world is not a VAX. Now we have it guaranteed that 'sizeof' units are characters, and I would have preferred a uniform guarantee about bits instead (yeah, I know this would limit the maximum size of an object to a fraction of address space on many machines). 2) In Classic C bitfields could be either int or unsigned at the whim of the implementation, and any specification to the contrary could be ignored. In C++ we are now guaranteed that the type of a bit field is either unsigned or int precisely as we declare it. This I like, because the Classic C rule was very unorthogonal, and made bitfields essentially useless without some regrettable limitations and contortions in their use. -- Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk