Xref: utzoo comp.lang.c++:6941 comp.std.c:2653 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!snorkelwacker!bloom-beacon!athena.mit.edu!raeburn From: raeburn@athena.mit.edu (Ken Raeburn) Newsgroups: comp.lang.c++,comp.std.c Subject: Re: references to dereferenced null pointers Message-ID: <1990Mar23.072132.7307@athena.mit.edu> Date: 23 Mar 90 07:21:32 GMT References: <51083@microsoft.UUCP> <25EB8EE8.8462@paris.ics.uci.edu> <1990Mar12.175613.12082@utzoo.uucp> <1623@argus.UUCP> Sender: news@athena.mit.edu (News system) Reply-To: Ken Raeburn Organization: MIT Project Athena Lines: 35 In article , roberto@ssd.csd.harris.com (Roberto Shironoshita) writes: [Dec '88 dpANS says:] > \begin{quote} > An integral constant expression with the value 0, or such an > expression cast to type void *, is called a _null pointer > constant_. (...) > \end{quote} > > So the implementation has two choices: > > #define NULL 0 > or > #define NULL (void *)0 A small point of the logic of these arguments is nagging at me. Does the standard say that values equivalent to (void *)0 in pointer contexts cannot be used for the definition of NULL? Just to be weird, let us consider a machine/compiler combination which has a integral type that has more bits than a pointer uses. Say the machine uses 24 bits for addressing, and a "long int" provides 32. Could not "(void *) 0xc0000000" be used for NULL? The compiler would have to understand that the top bits should be stripped out for comparisons, or the architecture could provide a pointer-compare instruction; would it need to provide anything else? Or is this simply disallowed because the standard is worded wrong? Or is there something fundamental about it I am missing that would make it fail miserably? It would probably be a strange architecture that would do things this way, but I expect there are some strange architectures out there, each with its own reasons. -- Ken