|Permuting fields of records email@example.com (1993-06-04)|
|C structure padding firstname.lastname@example.org (1993-06-26)|
|Re: C structure padding email@example.com (1993-06-27)|
|Re: C structure padding firstname.lastname@example.org (Tom Lord) (1993-06-27)|
|Re: C structure padding email@example.com (1993-06-27)|
|Re: C structure padding firstname.lastname@example.org (1993-06-28)|
|Re: C structure padding email@example.com (1993-06-28)|
|Re: C structure padding firstname.lastname@example.org (1993-06-29)|
|From:||email@example.com (Jim Balter)|
|Organization:||Netcom - Online Communication Services (408 241-9760 guest)|
|Date:||Sun, 27 Jun 1993 23:37:54 GMT|
>I recall nothing in the Standard which prevents the compiler from
>doing such tricks. But the code
> struct tag v;
> char p;
> struct tag w;
> char q;
> memcpy(w, v, sizeof(w));
>would mess up p and q if the compiler packed them into the padding of
>v and w.
Your statement is self-contradictory. Since the semantics of objects and
memcpy as given by the Standard does not allow that memcpy to modify q
(otherwise "messing up q" would be allowed), the Standard prevents such a
trick. The Standard need not address each possible way a compiler could
be implemented to violate its semantics.
Summary: sizeof any instance of a given struct is the same. structs within
arrays are aligned. structs cannot begin with padding.
Thus, structs must end with padding if needed to align the next
array member. sizeof includes the size of the padding; the padding
is part of the struct, it doesn't simply occur between structs.
q and w must not overlap.
Each of these points can be verified by close reading of the
J Q B firstname.lastname@example.org
Return to the
Search the comp.compilers archives again.