Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!brl-adm!brl-sem!ron From: ron@brl-sem.ARPA (Ron Natalie ) Newsgroups: comp.lang.c Subject: Re: structure element offsets Message-ID: <509@brl-sem.ARPA> Date: Tue, 9-Dec-86 00:19:57 EST Article-I.D.: brl-sem.509 Posted: Tue Dec 9 00:19:57 1986 Date-Received: Tue, 9-Dec-86 05:11:42 EST References: <1096@spice.cs.cmu.edu> <768@nike.UUCP> <3622@watmath.UUCP> <3810@watmath.UUCP> Organization: Electronic Brain Research Lab Lines: 18 Keywords: structure, offset In article <3810@watmath.UUCP>, rbutterworth@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.