void* (was: %p and different pointer representations)

Doug Gwyn gwyn at smoke.BRL.MIL
Tue Feb 28 02:49:37 AEST 1989


In article <597 at jhereg.Jhereg.MN.ORG> mark at jhereg.MN.ORG (Mark H. Colburn) writes:
>...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?

For improved type checking.  void* is intended to replace traditional
use of char* as a generic data pointer type.  Dennis promised everyone
at one time, informally, that char* could be used as a generic pointer.
I don't think he took into account the difference between data and
function pointer requirements for some architectures, as recently
discussed here; certainly it is undesirable for char* to be fatter
than necessary for use as a data byte pointer.  void*, as the new
officially-approved "generic" pointer, has to face the same decision.
The fairly recent guarantee that void* and char* have the same
representation is necessitated by the otherwise mismatch between
existing code and the definition of functions such as mem*() in terms
of generic data pointers.

By the way, I personally DO agree with the decision to introduce a
generic object pointer, to allow strict type checking of char* usage.

>By the way, before Doug slams me for not participating in the comment cycle
>of the standard, ...

My "slam" at Chris was inspired by the tone of his remarks and the
fact that he keeps repeating such criticism.  Your input into the
process, however it occurred, was certainly appreciated, and all
such input was considered by the Committee, even informal comments
(which technically we were not obliged to consider).

>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.

It's not that bad.  One can use a union type to hold a "generic"
function pointer.  Since there is no portable way to combine object
and function pointers anyway, this doesn't seem like much of a
constraint.  The only thing lacking, really, is a portable way to
print out a function pointer.  (Of course, the format of what is
printed wouldn't be consistent across systems.)  Since I'm not too
fond of %p you can imagine that I'm not much concerned about the
lack of a similar mechanism for function pointers.  I'd much rather
see the NAME of the function, for debugging purposes, and there are
other ways to do that.



More information about the Comp.lang.c mailing list