[9fans] 8c padding problem - Plan9

This is a discussion on [9fans] 8c padding problem - Plan9 ; i've got a structure that looks like this /* ethernet header */ typedef struct{ uchar d[6]; uchar s[6]; uchar type[2]; }Ehdr; typedef struct{ Ehdr; uchar op[2]; ... }Pkt; the problem is that 8c adds two bytes of padding between the ...

+ Reply to Thread
Results 1 to 11 of 11

Thread: [9fans] 8c padding problem

  1. [9fans] 8c padding problem

    i've got a structure that looks like this

    /* ethernet header */
    typedef struct{
    uchar d[6];
    uchar s[6];
    uchar type[2];
    }Ehdr;

    typedef struct{
    Ehdr;
    uchar op[2];
    ...
    }Pkt;

    the problem is that 8c adds two bytes of padding between
    the end of pkt->type and pkt->op. since sizeof Ehdr%wordsize != 0
    this isn't totally unexpected. suprisingly, adding the
    appropriate packed pragmas doesn't eliminate the padding.
    is this a bug?

    of course, if my original definition had been

    typedef struct{
    uchar d[6];
    uchar s[6];
    uchar type[2];
    uchar op[2];
    ...
    }Pkt;

    i would have been fine. but doesn't this defeat
    the point of unnamed structures?

    also, the fact that there is padding contradicts
    my mental model of unnamed structures. i thought
    that all the elements of unnamed structures were
    laid down as if they were elements of the enclosing
    structure. my reading /sys/doc/compilers.ps doesn't
    say much. is there another reference on unnamed
    structures?

    - erik

  2. Re: [9fans] 8c padding problem

    Not exactly answering your question, but I'm not sure 8c gives meaning to
    #pragma pack. (I'm not starting to argue about exploiting the memory layout
    of structs...)

    Martin


  3. Re: [9fans] 8c padding problem

    i am guessing that the requirement of being able to demote a type to
    one of its anonymouse constituents -- as in Node to Lock in Ken's example --
    would require a uniform layout that makes it easy to calculate the offset.

    > i've got a structure that looks like this
    >
    > /* ethernet header */
    > typedef struct{
    > uchar d[6];
    > uchar s[6];
    > uchar type[2];
    > }Ehdr;
    >
    > typedef struct{
    > Ehdr;
    > uchar op[2];
    > ...
    > }Pkt;
    >
    > the problem is that 8c adds two bytes of padding between
    > the end of pkt->type and pkt->op. since sizeof Ehdr%wordsize != 0
    > this isn't totally unexpected. suprisingly, adding the
    > appropriate packed pragmas doesn't eliminate the padding.
    > is this a bug?
    >
    > of course, if my original definition had been
    >
    > typedef struct{
    > uchar d[6];
    > uchar s[6];
    > uchar type[2];
    > uchar op[2];
    > ...
    > }Pkt;
    >
    > i would have been fine. but doesn't this defeat
    > the point of unnamed structures?
    >
    > also, the fact that there is padding contradicts
    > my mental model of unnamed structures. i thought
    > that all the elements of unnamed structures were
    > laid down as if they were elements of the enclosing
    > structure. my reading /sys/doc/compilers.ps doesn't
    > say much. is there another reference on unnamed
    > structures?
    >
    > - erik



  4. Re: [9fans] 8c padding problem

    > i am guessing that the requirement of being able to demote a type to
    > one of its anonymouse constituents -- as in Node to Lock in Ken's example --
    > would require a uniform layout that makes it easy to calculate the offset.


    however this is the opposite case. the padding is after the
    anon. structure. the anon. structure itself is at offset 0.

    - erik

  5. Re: [9fans] 8c padding problem

    >> i am guessing that the requirement of being able to demote a type to
    >> one of its anonymouse constituents -- as in Node to Lock in Ken's example --
    >> would require a uniform layout that makes it easy to calculate the offset.

    >
    > however this is the opposite case. the padding is after the
    > anon. structure. the anon. structure itself is at offset 0.


    but it doesn't have to be. this is legit:

    typedef struct{
    Ehdr; // 1
    Ehdr; // 2
    uchar op[2];
    }Pkt;


  6. Re: [9fans] 8c padding problem

    > Not exactly answering your question, but I'm not sure 8c gives meaning to
    > #pragma pack. (I'm not starting to argue about exploiting the memory layout
    > of structs...)
    >
    > Martin


    my syntax was incorrect. it's

    #pragma pack on

    - erik

  7. Re: [9fans] 8c padding problem

    > but it doesn't have to be. this is legit:
    >
    > typedef struct{
    > Ehdr; // 1
    > Ehdr; // 2
    > uchar op[2];
    > }Pkt;


    my explinations stink. perhaps this gets at what
    i'm saying better. the structure S0 won't have
    any padding, yet the two calls to frobehdr are
    just fine. i'm not sure i see the alignment problem
    that requires padding all unnamed structures.

    typedef struct{
    uchar s[6];
    uchar d[6];
    uchar t[2]
    }Ehdr;

    frobehdr(Ehdr*)

    typedef struct{
    uchar s0[6];
    uchar d0[6];
    uchar t0[2]
    uchar s1[6];
    uchar d1[6];
    uchar t1[2]
    }S0;

    void
    thunk0(void)
    {
    S0 *s;
    frobehdr((Ehdr*)s->s0);
    frobehdr((Ehdr*)s->s1);
    }


    - erik

  8. Re: [9fans] 8c padding problem

    excuse me. that's what hjdicks was for .. and it's called pack. ok.

    abuse them or yourselfs for using such code.

    brucee

    On Dec 22, 2007 11:20 AM, erik quanstrom wrote:
    > > but it doesn't have to be. this is legit:
    > >
    > > typedef struct{
    > > Ehdr; // 1
    > > Ehdr; // 2
    > > uchar op[2];
    > > }Pkt;

    >
    > my explinations stink. perhaps this gets at what
    > i'm saying better. the structure S0 won't have
    > any padding, yet the two calls to frobehdr are
    > just fine. i'm not sure i see the alignment problem
    > that requires padding all unnamed structures.
    >
    > typedef struct{
    > uchar s[6];
    > uchar d[6];
    > uchar t[2]
    > }Ehdr;
    >
    > frobehdr(Ehdr*)
    >
    > typedef struct{
    > uchar s0[6];
    > uchar d0[6];
    > uchar t0[2]
    > uchar s1[6];
    > uchar d1[6];
    > uchar t1[2]
    > }S0;
    >
    > void
    > thunk0(void)
    > {
    > S0 *s;
    > frobehdr((Ehdr*)s->s0);
    > frobehdr((Ehdr*)s->s1);
    > }
    >
    >
    > - erik
    >


  9. Re: [9fans] 8c padding problem

    > excuse me. that's what hjdicks was for .. and it's called pack. ok.
    >
    > abuse them or yourselfs for using such code.
    >
    > brucee


    what's the alternative? what i can think of is either
    cutting & pasting the repeated elements or not using
    unnamed structures at all. unfortunately, that results
    in awful code like so

    h = (hdr*)buf;
    p = (proto*)h->data;
    e = (subprobo*)p->data;

    - erik

  10. Re: [9fans] 8c padding problem

    easy. don't do it. marshall it or go insane.

    guess why the IP stack is so ambivalent. it's good.

    happy solstice recover.

    brucee

    On Dec 22, 2007 3:34 PM, erik quanstrom wrote:
    > > excuse me. that's what hjdicks was for .. and it's called pack. ok.
    > >
    > > abuse them or yourselfs for using such code.
    > >
    > > brucee

    >
    > what's the alternative? what i can think of is either
    > cutting & pasting the repeated elements or not using
    > unnamed structures at all. unfortunately, that results
    > in awful code like so
    >
    > h = (hdr*)buf;
    > p = (proto*)h->data;
    > e = (subprobo*)p->data;
    >
    > - erik
    >


  11. Re: [9fans] 8c padding problem

    an unnamed structure is not equivalent to laying down its members
    in the containing thing. it's equivalent to a field of that structure type with a name that
    does not occur anywhere else, and subject to the same rules.
    it's not intended for data layout but in general to avoid flatulent guff like
    u.s1.s2.u.s3.fred

+ Reply to Thread