structure element offsets

[brett at wjvax.UUCP]

In article <509 at brl-sem.ARPA> ron at brl-sem.ARPA (Ron Natalie <ron>) writes:
>In article <3810 at watmath.UUCP>, rbutterworth at watmath.UUCP (Ray Butterworth) writes:
>> > According to K&R all
>> > some machines in which pointers to different types are unrelated
>> > in format.  In other words a cast such as (type1 *)(type2 *)x
>> > will not always give a meaningful answer.
>> True.  But I wasn't talking about (type1*), I was talking about
>> (char*).  As far as I know, any (type2*) can be cast into a (char*)
>> and back again without harm on any machine.  (otherwise how does
>> malloc() work?) And any two (char*) pointers can be subtracted to
>> produce the number of bytes between them.
>> 
>What malloc provides is a (char *) that can be cast into other pointer
>types.  There is no guarantee that all legitimate pointer values can
>be represented by a (char *) cast of them.  Malloc is one of those very
>machine dependant magic routines that is careful to return very "special"
>character pointers that can be used as other data types, but to imply that
>the compiler always allows character pointers to be used for this mode
>is naive.

Except for the case of function pointers, I can't think of any reason why
converting type * to char * and back should not be valid.  Char * is
guaranteed to be the least-aligned pointer (since chars have no alignment
restrictions), so as long as we are talking about normal data pointers,
casting to char * and back should cause no loss of information.

What of previous attempts to guarantee the use void * as such a universally
least-aligned pointer?
-- 
-------------
Brett Galloway
{pesnta,twg,ios,qubix,turtlevax,tymix,vecpyr,certes,isi}!wjvax!brett