When I copy the contents of one structure into another, I want to
make sure that I copy everything, including any unnamed padding.
This is guaranteed if I use memcpy or memmove, as follows:
struct foo {
char a;
long b;
} foo1, foo2;
memcpy(&foo1, &foo2, sizeof(struct foo));
However, I can't find anything in the Standard about what happens
to the unnamed padding when the = operator is used, as follows:
foo1 = foo2;
Section 3.3.16.1 says that "the value of the right operand is
converted to the type of the assignment expression and replaces
the value stored in the object designated by the left operand."
But does the value of a structure object include its unnamed
padding?
(As an aside, is the Standard available in machine-readable
format? I would love to be able to grep for stuff, like
"padding".)
--
Joe Schwartz E-mail: x...@acm.rpi.edu or x...@clotho.acm.rpi.edu
MapInfo Corp.
200 Broadway These are my own opinions. Any similarity to the
Troy, NY 12180 opinions of MapInfo Corporation is purely coincidental.
That's right. No promises are made. The compiler *could* do a
component-by-component copy, ignoring the padding entirely. Or
it might copy some of the padding but not all of it (think of a
32-bit machine which imposes a 64-bit alignment requirement on
some types, and hence some structures -- if you've got a whole
32-bit word of padding at the end of a structure, you might get
a noticeable speedup by not copying it). It might even have
the values of all the components in registers from previous
computations, so it can just store them into the destination
without ever looking at memory.
>(As an aside, is the Standard available in machine-readable
>format? ...
No. It's copyrighted (well, some doubts have been raised, but
ANSI certainly *claims* copyright) and the publisher has opted to
distribute only in hardcopy.
--
Altruism is a fine motive, but if you | Henry Spencer @ U of Toronto Zoology
want results, greed works much better. | he...@zoo.toronto.edu utzoo!henry