* [9fans] 8c padding problem
@ 2007-12-21 23:10 erik quanstrom
2007-12-21 23:24 ` Martin Neubauer
2007-12-21 23:48 ` Skip Tavakkolian
0 siblings, 2 replies; 11+ messages in thread
From: erik quanstrom @ 2007-12-21 23:10 UTC (permalink / raw)
To: 9fans
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] 8c padding problem
2007-12-21 23:10 [9fans] 8c padding problem erik quanstrom
@ 2007-12-21 23:24 ` Martin Neubauer
2007-12-22 0:00 ` erik quanstrom
2007-12-21 23:48 ` Skip Tavakkolian
1 sibling, 1 reply; 11+ messages in thread
From: Martin Neubauer @ 2007-12-21 23:24 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] 8c padding problem
2007-12-21 23:10 [9fans] 8c padding problem erik quanstrom
2007-12-21 23:24 ` Martin Neubauer
@ 2007-12-21 23:48 ` Skip Tavakkolian
2007-12-21 23:52 ` erik quanstrom
2007-12-22 11:09 ` C H Forsyth
1 sibling, 2 replies; 11+ messages in thread
From: Skip Tavakkolian @ 2007-12-21 23:48 UTC (permalink / raw)
To: 9fans
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] 8c padding problem
2007-12-21 23:48 ` Skip Tavakkolian
@ 2007-12-21 23:52 ` erik quanstrom
2007-12-21 23:59 ` Skip Tavakkolian
2007-12-22 11:09 ` C H Forsyth
1 sibling, 1 reply; 11+ messages in thread
From: erik quanstrom @ 2007-12-21 23:52 UTC (permalink / raw)
To: 9fans
> 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] 8c padding problem
2007-12-21 23:52 ` erik quanstrom
@ 2007-12-21 23:59 ` Skip Tavakkolian
2007-12-22 0:20 ` erik quanstrom
0 siblings, 1 reply; 11+ messages in thread
From: Skip Tavakkolian @ 2007-12-21 23:59 UTC (permalink / raw)
To: 9fans
>> 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;
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] 8c padding problem
2007-12-21 23:24 ` Martin Neubauer
@ 2007-12-22 0:00 ` erik quanstrom
0 siblings, 0 replies; 11+ messages in thread
From: erik quanstrom @ 2007-12-22 0:00 UTC (permalink / raw)
To: 9fans
> 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] 8c padding problem
2007-12-21 23:59 ` Skip Tavakkolian
@ 2007-12-22 0:20 ` erik quanstrom
2007-12-22 4:25 ` Bruce Ellis
0 siblings, 1 reply; 11+ messages in thread
From: erik quanstrom @ 2007-12-22 0:20 UTC (permalink / raw)
To: 9fans
> 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] 8c padding problem
2007-12-22 0:20 ` erik quanstrom
@ 2007-12-22 4:25 ` Bruce Ellis
2007-12-22 4:34 ` erik quanstrom
0 siblings, 1 reply; 11+ messages in thread
From: Bruce Ellis @ 2007-12-22 4:25 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
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
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] 8c padding problem
2007-12-22 4:25 ` Bruce Ellis
@ 2007-12-22 4:34 ` erik quanstrom
2007-12-22 4:41 ` Bruce Ellis
0 siblings, 1 reply; 11+ messages in thread
From: erik quanstrom @ 2007-12-22 4:34 UTC (permalink / raw)
To: 9fans
> 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] 8c padding problem
2007-12-22 4:34 ` erik quanstrom
@ 2007-12-22 4:41 ` Bruce Ellis
0 siblings, 0 replies; 11+ messages in thread
From: Bruce Ellis @ 2007-12-22 4:41 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
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
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] 8c padding problem
2007-12-21 23:48 ` Skip Tavakkolian
2007-12-21 23:52 ` erik quanstrom
@ 2007-12-22 11:09 ` C H Forsyth
1 sibling, 0 replies; 11+ messages in thread
From: C H Forsyth @ 2007-12-22 11:09 UTC (permalink / raw)
To: 9fans
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
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2007-12-22 11:09 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-12-21 23:10 [9fans] 8c padding problem erik quanstrom
2007-12-21 23:24 ` Martin Neubauer
2007-12-22 0:00 ` erik quanstrom
2007-12-21 23:48 ` Skip Tavakkolian
2007-12-21 23:52 ` erik quanstrom
2007-12-21 23:59 ` Skip Tavakkolian
2007-12-22 0:20 ` erik quanstrom
2007-12-22 4:25 ` Bruce Ellis
2007-12-22 4:34 ` erik quanstrom
2007-12-22 4:41 ` Bruce Ellis
2007-12-22 11:09 ` C H Forsyth
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).