Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c > #18332

Re: partial struct usage

From Tim Rentsch <txr@alumni.caltech.edu>
Newsgroups comp.lang.c
Subject Re: partial struct usage
Date 2012-03-08 09:38 -0800
Organization A noiseless patient Spider
Message-ID <kfnboo7t2m7.fsf@x-alumni2.alumni.caltech.edu> (permalink)
References <2011092410234736215-madler@alumnicaltechedu> <87vcshy8wu.fsf@bazspaz.fatphil.org> <kfnty3kejt6.fsf@x-alumni2.alumni.caltech.edu> <8739agvrmk.fsf@bazspaz.fatphil.org>

Show all headers | View raw


Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes:
>> 
>> > Mark Adler <madler@alumni.caltech.edu> writes:
>> >> I have an internal structure with lots of stuff in it for controlling
>> >> a data input operation.  E.g.:
>> >> 
>> >> struct data {
>> >>     int have;
>> >>     char *next;
>> >>     ... lots more stuff to keep track of the state
>> >> };
>> >> 
>> >> I would like to expose to the user (in the interface header file) only
>> >> those first two elements, so that I can provide a macro (also in the
>> >> header file) analogous to getc() to pull data that is readily
>> >> available in the buffer, otherwise to call a function to go get more
>> >> data.  But I want to hide the other stuff in the structure, in order
>> >> to make sure that users of the library don't end up depending on
>> >> things that I change later for internal use.  And for efficiency I
>> >> don't want yet another layer of indirection pointing to another
>> >> structure from within the exposed structure for the other stuff.
>> >> 
>> >> E.g.
>> >> 
>> >> struct ex {
>> >>     int have;
>> >>     char *next;
>> >> };
>> >> 
>> >> #define getd(d) (((struct ex *)d)->have ? (((struct ex *)d)->have--,
>> >> *(((struct ex *)d)->next)++) : getdf(d))
>> >> 
>> >> where d is a struct data *.
>> >> 
>> >> My question is: does the C standard provide an assurance that this
>> >> will work?  I.e. that two different structures with identical sets of
>> >> prefix elements will have those prefix elements layed out identically
>> >> in memory so that casting one structure to the other will permit
>> >> correct access to those prefix elements?
>> >
>> > struct private {
>> >         struct public {
>> >                 int have;
>> >                 char *next;
>> >         } pub;
>> >         other stuff;
>> > }
>> >
>> > let the clients see and pass around pointers to pub, and then either
>> > use something like container_of() (which is not strictly portable), or
>> 
>> Actually container_of() should be strictly portable provided the
>> outer structure type being casted to matches the actual object
>> being referred to.  (This assuming container_of() is defined
>> properly.)
>
> All the implementations I've seen (which isn't a huge number) have
> implemented container_of as an almost identical macro in a way that I
> would consider non-portable. Looking more closely, I'm fairly sure
> that this nonportability is historical accident being propagated
> rather than actually being necessary. Nothing more than casting to
> character pointer, subtracting offset_of, and casting again should
> work portably (given the provision you mention).

I see, that's interesting.  Do you know what the original
motivation was for defining it that way, rather than (what
seems to me to be) the more straightfoward portable one?

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

partial struct usage Mark Adler <madler@alumni.caltech.edu> - 2011-09-24 10:23 -0700
  Re: partial struct usage Richard Damon <news.x.richarddamon@xoxy.net> - 2011-09-24 13:44 -0400
    Re: partial struct usage Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-24 14:08 -0800
  Re: partial struct usage BGB <cr88192@hotmail.com> - 2011-09-24 11:08 -0700
  Re: partial struct usage Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-09-24 23:36 +0300
    Re: partial struct usage Mark Adler <madler@alumni.caltech.edu> - 2011-09-25 13:23 -0700
      Re: partial struct usage Gene <gene.ressler@gmail.com> - 2011-09-26 01:14 -0700
        Re: partial struct usage Richard Damon <news.x.richarddamon@xoxy.net> - 2011-09-26 12:37 -0400
          Re: partial struct usage Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-24 16:04 -0800
        Re: partial struct usage Mark Adler <madler@alumni.caltech.edu> - 2011-09-26 18:52 -0700
          Re: partial struct usage Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-09-27 12:14 +0100
    Re: partial struct usage Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-24 15:56 -0800
      Re: partial struct usage Shao Miller <sha0.miller@gmail.com> - 2012-01-24 23:30 -0500
        Re: partial struct usage Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-31 16:11 -0800
          Re: partial struct usage Shao Miller <sha0.miller@gmail.com> - 2012-02-01 00:42 -0500
            Re: partial struct usage Tim Rentsch <txr@alumni.caltech.edu> - 2012-03-08 09:33 -0800
      Re: partial struct usage Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-02-12 02:10 +0200
        Re: partial struct usage Tim Rentsch <txr@alumni.caltech.edu> - 2012-03-08 09:38 -0800
          Re: partial struct usage Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-03-13 18:22 +0200
            Re: partial struct usage blp@cs.stanford.edu (Ben Pfaff) - 2012-03-13 09:55 -0700
  Re: partial struct usage Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-09-24 17:56 -0400

csiph-web