Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!ginosko!husc6!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.lang.c
Subject: Re: offsetof() macro
Message-ID: <10828@smoke.BRL.MIL>
Date: 28 Aug 89 03:44:06 GMT
References: <70@motto.UUCP> <1629@cbnewsl.ATT.COM>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 16

In article <1629@cbnewsl.ATT.COM> dfp@cbnewsl.ATT.COM (david.f.prosser) writes:
>	(size_t)(((char *)&(((_type_*)&X)->_member_))-((char *)&X))
>where in the last X is some predeclared static object address.
>None of these are portable.

But this last one is pretty close, if X is changed to __X and made
an extern struct { double __d; char __pad[__UMPTEEN]; } __X; which has
probably pessimal alignment constraints (you could change the double to
a fancy union to make sure).  The Standard allows pointers to tough
alignments to be converted to pointers to easy alignments without problem.
The only practical problem remaining would be if the offset to the member
exceeded the valid pointer range for the __X object and if this mattered
(as it might, on a segmented architecture); if you make __UMPTEEN big
enough this problem could be avoided, at the cost of wasted data space.
(Perhaps the space could hold genuine C library data objects, with __X
just an entry point labeling the beginning of the data space.)