[9fans] 8c padding problem

[9fans] 8c padding problem

[erik quanstrom]

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

Re: [9fans] 8c padding problem

[Martin Neubauer]

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

Re: [9fans] 8c padding problem

[erik quanstrom]

> 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

Re: [9fans] 8c padding problem

[Skip Tavakkolian]

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

Re: [9fans] 8c padding problem

[erik quanstrom]

> 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

Re: [9fans] 8c padding problem

[Skip Tavakkolian]

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

Re: [9fans] 8c padding problem

[erik quanstrom]

> 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

Re: [9fans] 8c padding problem

[Bruce Ellis]

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 <quanstro@quanstro.net> 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
>

Re: [9fans] 8c padding problem

[erik quanstrom]

> 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

Re: [9fans] 8c padding problem

[Bruce Ellis]

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 <quanstro@quanstro.net> 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
>

Re: [9fans] 8c padding problem

[C H Forsyth]

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