This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH]: Fix PR tree-optimization/21407
jakub@redhat.com (Jakub Jelinek) wrote on 12.05.05 in <20050512120655.GT17420@devserv.devel.redhat.com>:
> On Wed, May 11, 2005 at 12:35:53PM -0700, Zack Weinberg wrote:
> > Mike Stump <mrs@apple.com> writes:
> >
> > > On May 11, 2005, at 5:25 AM, Kenneth Zadeck wrote:
> > >> I wonder, Mike, do you make any distinction between a c program
> > >> that upcasts on the first field of a record and one that uses the
> > >> offsetof operator to upcast from the middle of a record?
> > >
> > > I don't, but Geoff does as I recall, which is I think what your
> > > question was.
> > [...]
> >
> > I must point out that upcasting from the middle of a record is used in
> > GCC itself:
> >
> > /* Translate a hash table identifier pointer to a tree_identifier
> > pointer, and vice versa. */
> >
> > #define HT_IDENT_TO_GCC_IDENT(NODE) \
> > ((tree) ((char *) (NODE) - sizeof (struct tree_common)))
> > #define GCC_IDENT_TO_HT_IDENT(NODE) (&((struct tree_identifier *)
> > (NODE))->id)
>
> And so does glibc, e.g.:
> tmap = (struct link_map *) ((char *) imap->l_scope[cnt]
> - offsetof (struct link_map,
> l_searchlist));
> where map->l_scope[cnt] is known to be either NULL, &map->l_local_searchlist
> (but only for the current map, so checked first) or &othermap->l_searchlist
> (of arbitrary link map).
And so does the Linux kernel, though I don't have a snippet handy.
Embedding structs and recovering the outer from the inner using offsetof
is an important part of the basic design.
MfG Kai