Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.UUCP
Newsgroups: comp.lang.c
Subject: Re: Is an object made up of bytes?
Message-ID: <5555@brl-smoke.ARPA>
Date: Fri, 23-Jan-87 17:18:00 EST
Article-I.D.: brl-smok.5555
Posted: Fri Jan 23 17:18:00 1987
Date-Received: Mon, 26-Jan-87 01:39:46 EST
References: <2144@brl-adm.ARPA> <5497@brl-smoke.ARPA> <5527@brl-smoke.ARPA> <5536@brl-smoke.ARPA> <812@wjvax.wjvax.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 41

In article <812@wjvax.wjvax.UUCP> brett@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.