Path: utzoo!mnetor!uunet!husc6!bu-cs!polygen!pablo
From: pablo@polygen.uucp (Pablo Halpern)
Newsgroups: comp.lang.c
Subject: Re: Why NULL is 0
Message-ID: <124@polygen.UUCP>
Date: 11 Mar 88 02:57:33 GMT
References: <10576@mimsy.UUCP>
Organization: Polygen Corporation, Waltham, MA
Lines: 29

From article <10576@mimsy.UUCP>, by chris@mimsy.UUCP (Chris Torek):
> (You may wish to save this, keeping it handy to show to anyone who
> claims `#define NULL 0 is wrong, it should be #define NULL <xyzzy>'.
> I intend to do so, at any rate.)
> 
> Let us begin by postulating the existence of a machine and a compiler
> for that machine.  This machine, which I will call a `Prime', or
> sometimes `PR1ME', for obscure reasons such as the fact that it
> exists, has two kinds of pointers.  `Character pointers', or objects
> of type (char *), are 48 bits wide.  All other pointers, such as
> (int *) and (double *), are 32 bits wide.

I must admit, you have come up with a situation where the uncasted
value NULL would be an incorrect parameter to a function that didn't
have a prototype regardless of the definition of NULL. (If you missed
the original posting, please don't flame about this.  Ask someone to
mail the original to you.)  In the situation mentioned, the compiler
could not know how wide to make the null pointer when passing it to the
function.  Indeed, even with NULL defined as (void *) 0, dpANS does not
say that the size of a (void *) is the same as the size of any other
pointer.

However, if I were writing a C compiler, I would choose a size for all
pointers equal to the size of the largest possible pointer.  This would
allow code that passed uncasted NULL to work correctly, provided NULL
is a type as large as a pointer.  This is not because dpANS says it
should be so, but because so much code would break if it were not.
Perhaps ANSI should add the restriction that all pointer types must be
the same size in an effort to "codify common existing practice."