Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!adm!MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU
From: MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU
Newsgroups: comp.lang.c
Subject: Undelivered mail
Message-ID: <12362@brl-adm.ARPA>
Date: 13 Mar 88 15:39:57 GMT
Sender: news@brl-adm.ARPA
Lines: 48

Subject:  Re: Why NULL is 0

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 1135
          for SXJVK@ALASKA; Sun, 13 Mar 88 06:01 AST
Received: by UWAVM (Mailer X1.25) id 7048; Sun, 13 Mar 88 07:01:00 PST
Date:         Sat, 12 Mar 88 19:07:25 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         "Stephen J. Friedl" <friedl@vsi.uucp>
Subject:      Re: Why NULL is 0
Comments: To: info-c@BRL-SMOKE.arpa
To:           Vic Kapella <SXJVK@ALASKA>

In article <124@polygen.UUCP>, pablo@polygen.uucp (Pablo Halpern) writes:
> 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."

I think this is naive.  Presumably, the large "common" pointer
format would pass around the machine OK but it still must be
converted to the machine's native pointer types to actually
use -- how efficiently will this be done?  This might be like the 80x86
huge pointer calculations or the old promote-float-to-double
rules -- they makes life a little easier for the (lazy?)
programmer at the larger expense in time and compiler complexity

Perhaps more reasonable is to promote all pointers to the same
large width while passing them on the stack and convert them back
on the other end: this would fix the alignment issues but would
still slow things down.

I don't favor this approach but I bring it up in the spirit of
this discussion.  The obvious answer is to be very rigorous about
casting your pointers and knowing when to do so.  This is a
bummer for the beginners but we all had to go through it unless
we develop on a VAX :-).
--
Life : Stephen J. Friedl @ V-Systems, Inc./Santa Ana, CA   *Hi Mom*
CSNet: friedl%vsi.uucp@kent.edu  ARPA: friedl%vsi.uucp@uunet.uu.net
uucp : {kentvax, uunet, attmail, ihnp4!amdcad!uport}!vsi!friedl