Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!ncar!tank!shamash!com50!jhereg!mark From: mark@jhereg.Jhereg.MN.ORG (Mark H. Colburn) Newsgroups: comp.lang.c Subject: Re: %p and different pointer representations Message-ID: <597@jhereg.Jhereg.MN.ORG> Date: 26 Feb 89 15:42:42 GMT References: <9382@bloom-beacon.MIT.EDU> <234@mstan.Morgan.COM> <16112@mimsy.UUCP> <592@jhereg.Jhereg.MN.ORG> <16120@mimsy.UUCP> Reply-To: mark@jhereg.MN.ORG (Mark H. Colburn) Organization: Minnetech Consulting, Inc., St. Paul, MN Lines: 49 Damn. I hate it when the article propagate faster than the cancel message that follows them... In article <16120@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >I do remember that, at one point, I thought (void *) had to hold >function pointers as well. Knowing of medium model and of that Sperry >compiler, I checked the then-current draft, and (after much squinting >and re-reading of fine print) discovering otherwise. This is the delusion that I was under as well. It turns out to be wrong. >>Also, I don't beleive that there is any requirement that (void *) has to be >>2 bytes long. In my opinion void should be defined to be at least as >>large as the largest pointer available in the current compiler model. Unfortunately, there is. I spent last night re-reading the pANS, and there is a paragraph which states that (void *) must be the same size and have the same alignment as (char *). This seems really silly to me. Why introduce a new type if it has no new functionality? I understand that the commitee did not want to break existing code, but if add a new feature... As soon as I found this out, I canceled the article, since it was definitely wrong. At the same time I prayed that it would not get out, but I knew better... By the way, before Doug slams me for not participating in the comment cycle of the standard, I did, however, I piggybacked on another persons ballot since I got involved to late to become a balloting member myself. Somehow I missed this when I was reviewing the standard. >I would agree. Alas, the standard says that (void *) and (char *) must >have the same representation, so to comply with our opinions (as >opposed to the letter of the proposed standard), an IBM PC compiler or >Sperry compiler or . . . would have to make (char *) be twice, or nine >times, or whatever, as big as necessary. (If the proposed standard >says only that (void *) must hold function pointers, one could avoid >this penalty for (char *) pointers.) True. My original concept of a void pointer was a pointer which was maximally aligned and large enough to hold any pointer. It would seem that this would be more useful that the (char *) paradigm that is being proposed. What it means, is that there is no portable way to pass an arbitrary pointer to a function or store one in a data structure. That is really too bad. -- Mark H. Colburn "Look into a child's eye; Minnetech Consulting, Inc. there's no hate and there's no lie; mark@jhereg.mn.org there's no black and there's no white."