%p and different pointer representations

Mark H. Colburn mark at jhereg.Jhereg.MN.ORG
Mon Feb 27 01:42:42 AEST 1989


Damn.  I hate it when the article propagate faster than the cancel message
that follows them...

In article <16120 at mimsy.UUCP> chris at 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 at jhereg.mn.org                there's no black and there's no white."



More information about the Comp.lang.c mailing list