Re^3: offsets in structures.

Sam Kendall kendall at wjh12.UUCP
Sun Oct 21 12:36:35 AEST 1984


> > [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



More information about the Comp.lang.c mailing list