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: <12260@brl-adm.ARPA>
Date: 12 Mar 88 05:19:22 GMT
Sender: news@brl-adm.ARPA
Lines: 39

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 6461
          for SXJVK@ALASKA; Fri, 11 Mar 88 19:45 AST
Received: by UWAVM (Mailer X1.25) id 4332; Fri, 11 Mar 88 20:43:57 PST
Date:         Fri, 11 Mar 88 23:28:50 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         David Keppel <pardo@june.cs.washington.EDU>
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."

My guess is that you would want to do this only if you didn't care
whether your compiler produced efficient code or made "reasonable"
time/space efficiency tradeoffs.

I know we've gone over this a lot, and perhaps the topic should be
redirected to comp.arch or some such, but (if nobody minds too much)
could somebody who understands please tell me what kind of efficiency
you lose (in runtime, codespace, and dataspace) in trying to make
everything the most general pointer type (on existing architectures)?

I'd sure like to know.

 ;-D on  (Well it looked like luminous phosphor when I wrote it)  Pardo