Re: C structure padding

>[re struct padding
>But is there a clear statement that if you bcopy over a struct, with a
>length of sizeof(the struct), that you won't affect some other object?
>Obviously, you don't want it to, but does the Standard actually *say* that
>anywhere?
>
>Dale Worley Dept. of Math., MIT drw@math.mit.edu
>[It says so indirectly -- routines like memcpy() take a length argument which
>is a size_t, and the only portable way to get a size-t is with sizeof. -John]


It is somewhat implicit that distinct objects do not overlap; if this were
not so, the compiler could overlap all variables. {int a, b; a = 1;}
mustn't modify b, although the Standard is less than explicit in saying
so. The most explicit language I can find upon brief examination is in
3.3: "An object shall have its stored value accessed only by one of the
following types: [...]". This disallows accessing q in {struct foo w;
char q;} via w. (It doesn't address overlap in general, however.)


Why does memcpy(w,v,sizeof(w)) play by the same rules as (w = v)? Because
the Standard defines memcpy in terms of objects. Note that memcpy(x,y,n)
is undefined if n > sizeof(x) or n > sizeof(y) (although, if x and y are
contained within aggregates, the behavior may be inferred).


BTW, discussions of this sort are, IMHO, a bit silly. There is no real
ambiguity of intent of the Standard, no real question of whether a
sensible implementation can do such overlap, since breaking
memcpy(w,v,sizeof(w)) would at the very least have a severe impact upon
"quality of implementation". I guess people are just bored, having
resolved all the real problems. :-)
--
<J Q B>
--

Return to the comp.compilers page.
Search the comp.compilers archives again.