Re: C structure padding (Jim Balter)
Mon, 28 Jun 1993 19:07:34 GMT

          From comp.compilers

Related articles
Permuting fields of records (1993-06-04)
C structure padding (1993-06-26)
Re: C structure padding (1993-06-27)
Re: C structure padding (Tom Lord) (1993-06-27)
Re: C structure padding (1993-06-27)
Re: C structure padding (1993-06-28)
Re: C structure padding (1993-06-28)
Re: C structure padding (1993-06-29)
| List of all articles for this month |

Newsgroups: comp.compilers
From: (Jim Balter)
Keywords: C
Organization: Compilers Central
References: 93-06-012 93-06-074
Date: Mon, 28 Jun 1993 19:07:34 GMT

>[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
>Dale Worley Dept. of Math., MIT
>[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>

Post a followup to this message

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