Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/3/84; site wjh12.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!godot!harvard!wjh12!kendall From: kendall@wjh12.UUCP (Sam Kendall) Newsgroups: net.lang.c Subject: Re^3: offsets in structures. Message-ID: <531@wjh12.UUCP> Date: Sat, 20-Oct-84 22:36:35 EDT Article-I.D.: wjh12.531 Posted: Sat Oct 20 22:36:35 1984 Date-Received: Mon, 22-Oct-84 01:55:03 EDT References: <527@wjh12.UUCP> <157@desint.UUCP> Organization: Delft Consulting Corp., New York Lines: 29 > > [An expression for finding the byte offset of an object:] > > (char *)(&((struct foo *)&end)->element) - (char *)&end > > Good idea, except am not sure &end is the best symbol to use. Is &end > actually guaranteed to refer to a legal address by itself? What about the > other "&e" symbols: etext and edata? Is it legal is we replace "&end" with > "(&end-sizeof (struct foo))"? > -- > Geoff Kuenning You have a good point. On a segmented architecture (8086 or Z8000), I suppose &end may point to a location which is less than sizeof (struct foo) bytes away from the end of a segment--either end. So neither "&end" nor "(&end-sizeof (struct foo))" (actually, it would have to be "((char *)&end - sizeof (struct foo))") is guaranteed to work, because either may cause the above expression to overflow a segment boundry. So the only solution is to use the address of an actual structure object. I am really thinking too low-level, I guess. If &end doesn't point to allocated storage, I should assume that pointer arithmetic on it is nonportable, on principle. However, it seems to me that UNIX tells you that &end points to a sort of variable-length "object", "the heap". This "object" starts out at zero bytes long, and "sbrk" and "brk" can be used to make it bigger. It is interesting that on segmented architectures, pointer relational comparison may not work between the ends of this "object". Sam Kendall {allegra,ihnp4,ima,amd}!wjh12!kendall Delft Consulting Corp. decvax!genrad!wjh12!kendall