Undelivered mail

MAILER%ALASKA.BITNET at CUNYVM.CUNY.EDU MAILER%ALASKA.BITNET at CUNYVM.CUNY.EDU
Sat Mar 12 15:19:22 AEST 1988


Subject:  Re: Why NULL is 0

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

Reply-To: Info-C at BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 6461
          for SXJVK at 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 at BRL.ARPA
Sender:       Info-C List <INFO-C at NDSUVM1>
From:         David Keppel <pardo at june.cs.washington.EDU>
Subject:      Re: Why NULL is 0
Comments: To: info-c at brl-smoke.arpa
To:           Vic Kapella <SXJVK at ALASKA>

In article <124 at polygen.UUCP> pablo at 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



More information about the Comp.lang.c mailing list