Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!think.com!zaphod.mps.ohio-state.edu!ncar!hsdndev!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.std.c
Subject: Re: Why no arithmetic on void *
Message-ID: <14949@smoke.brl.mil>
Date: 23 Jan 91 23:44:04 GMT
References: <1238@dkunix9.dk.oracle.com> <561@taumet.com> <1991Jan22.211212.14692@Think.COM>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 52

In article <1991Jan22.211212.14692@Think.COM> barmar@think.com (Barry Margolin) writes:
>However, it would be nice if void* could also be used as a way to pass
>pointers to an array of arbitrary objects.

There is essentially no difference between "object" and "array of objects"
in this context.  To access an object, first the void* must be converted
to a pointer to the desired type.  That could be a pointer to an array
type, if desired.

>[proposes] sizeof void == 1.

No, that would never be accepted, since (I believe) it is clear to most
X3J11 members that if we were to give an object meaning to void, then we
would have to require that sizeof(void)==0.  I was Point Of Contact for
the zero-sized object special interest group, and determined as a side
exercise just what would have to be specified in the standard were void
to acquire object meaning (similar to my proposal on changes needed to
support a "short char" type to designate sizeof units).

>For compatibility sizeof char would also be defined to be 1, but such
>use could be deprecated.  Future C standards might then be able to get rid
>of the notion that char is the fundamental unit ...

I argued for such a specification, prompted by the Japanese proposal for
"long char", but ultimately the explicit multibyte-character specifications
were adopted rather than the obviously cleaner solution of a basic type
whose size may be other than that of a char.  I won't rehash the pros and
cons here, but will note that it is unlikely this will ever be cleaned up,
because of the international momentum behind kludgier (multibyte character)
approaches.

However, trying to give "storage_unit*" semantics to void* is the wrong
approach.  "short char" or some such explicit object type would be the
technically appropriate method to provide for potentially sub-char
addressing.  As the standard is currently organized, void definitely
must not be given object meaning; therefore it would be might hard to
give void* the semantics you seek.

>My point is that char* is doing double duty, and it seems like void* was
>invented to take over the portion of char*'s role that has nothing to do
>with character data.

It is true that char (not just char *) has been overloaded with both
"character" and "byte" meanings.  This was, as noted above, a deliberate
decision of X3J11, although one which I disliked.  As the library section
of the standard evolved, it became clear that all "generic object"
pointer parameters to library routines such as memcpy() should be changed
to void* rather than char*.  This doesn't mean, however, that X3J11
believed that void* is the proper way to write "byte pointer"; char* is
also a "byte pointer", and the latter is the form one should use for
byte-oriented address arithmetic.  (Again, I'm not happy with that, but
that IS the position taken for the standard.)