Is an object made up of bytes?

gwyn at brl-smoke.UUCP gwyn at brl-smoke.UUCP
Sat Jan 24 08:18:00 AEST 1987


In article <812 at wjvax.wjvax.UUCP> brett at wjvax.UUCP (Brett Galloway) writes:
>I agree.  It seems odd, though, that (void *) and (char *) would behave
>differently.  I know that there is a lot of existing code that assumes
>that (char *) behaves this way.  This assumption is necessary because
>(void *) doesn't exist, and bcopy (or memc?py) on (char *)&foo is too
>useful.  Another example is writing data to a file -- how could one ever
>write anything but a character string to a file?  For example,
>to write an object
>	short foo;
>to a file, one must do something like
>	fwrite((char *)&foo,sizeof(short),1,file)
>at least in 4.2BSD.  In order to maintain this ability, it must be
>possible to obtain the "numeric address of an object which is the
>lowest-valued address of the bytes within the object."  One could make
>(void *) this object, but that is still not correct -- fwrite needs to
>dereference the pointer to the object to get characters, not "voids".
>I suppose one could do (char *)(void *)(&foo), but that is ugly.

Two points:

Actually I agree with the gist of your comments.  I briefly checked
this with Larry Rosler (the X3J11 Redactor) at USENIX, and my impression
of the outcome of our discussion is that X3J11 certainly intends that
the conversion (char *) produces the address of the lowest-addressed char
of the original referenced object.  However, I wasn't able to find an
explicit guarantee of this in the draft proposed standard.  This seems
like an oversight that needs to be remedied.

You should also realize that I am a proponent of a modification to the
standard to support chars that are more than one "byte" (basic storage
object accessible unit).  When I was drafting my proposal on this issue,
I observed the interesting phenomenon that all the void * parameters
in the draft referred to basic storage units and all the char *s were
used for actual character text, except for fread/fwrite which I think
need to be restricted to binary objects (basic storage units).  (I
would appreciate hearing of any significant use of these with textual
data.)  Since void * plays the role of a "lowest-common-denominator"
(i.e., generic) pointer, it is appropriate for it to have magical
properties, but if we establish the common idea of how chars (or other
byte-sized objects, in my scheme) are packed inside objects, there is
then no need for void * to be singled out specially in this regard.



More information about the Comp.lang.c mailing list