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