Do the padding bytes of a POD type get copied?

Question

Suppose I have a POD type like this:

struct A {
    char a;
    int b;
};

On my system, sizeof(A) == 8, even though sizeof(char) == 1 and sizeof(b) == 4. This means that the data structure has 3 unused bytes.

Now suppose we do

A x = ...;
A y =x;

Question:

Is it guaranteed that all 8 bytes of x and y will be identical, even those 3 unused ones?

Equivalently, if I transfer the underlying bytes of some A objects to another program that does not understand their meaning or structure, and treats them as an array of 8 bytes, can that other program safely compare two As for equality?

Note: In an experiment with gcc 7, it appears that those bytes do get copied. I would like to know if this is guaranteed.

I don't think the dupe answers the question "are the padding bytes the same". It only says that memcpy copies them, but that's not exactly what OP asked. — vsoftco, Oct 22 '17 at 14:21
@vsoftco *"`=` is only required to copy the members. It might or might not copy the padding."* Second paragraph in the top answer. — Baum mit Augen, Oct 22 '17 at 14:23
There is no guarantee that assignment or initialization will copy padding. In some cases it can be critical that it's *not* copied (padding can be reused in inheritance). `memcpy` will copy it though, because it doesn't know about it. — Cheers and hth. - Alf, Oct 22 '17 at 14:29
If you need to copy the padding bytes as well, you can do so with `memcpy()`. Another technique I’ve sometimes used in C is to set all the bytes of the structure to 0 with `memset()`, and *then* do your memberwise copy. Modern compilers have been able to optimize the redundant double writes away for more than a decade. — Davislor, Oct 23 '17 at 03:14

score 47 · Accepted Answer · answered Oct 22 '17 at 14:28

47

The implicitly-defined copy/move constructor for a non-union class X performs a memberwise copy/move of its bases and members.

12.8/15 [class.copy] in N4141

The bit pattern in the padding bytes is thus allowed to differ.

answered Oct 22 '17 at 14:28

Baum mit Augen

49,044
25
144
182

It's kind of unfortunate that N4141 is [password protected](https://stackoverflow.com/questions/27180058/which-c-draft). It looks like it is the final standard for C++14. A draft of which is [N4140](https://github.com/cplusplus/draft/blob/master/papers/n4140.pdf), the information is [from this Reddit thread](https://www.reddit.com/r/cpp/comments/2sewtw/c14_published_by_iso_today/). I can't say I trust that reddit thread 100%. In it, it's 12.8/16, not 15. Is there anywhere a directed graph where standards and drafts are nodes and an edge means _is part of_? – Stefan Hanke Oct 23 '17 at 07:12
3

@StefanHanke Actually, the source of N4141 is available on github, you just have to build it yourself. https://github.com/cplusplus/draft/tree/n4141 – Baum mit Augen Oct 23 '17 at 08:04
4

"Actually, the source of N4141 is available on github, you just have to build it yourself" That's a very C++ thing to say. – pmf Oct 23 '17 at 12:27
Does that mean it can't copy the padding bytes, or that it doesn't have to? (I figured under the as-if rule it could?) – Borgleader Aug 03 '18 at 17:28
@Borgleader I would not read that from the quote (i.e. I think it can copy). – Baum mit Augen Aug 03 '18 at 17:58
@BaummitAugen Hmm, I was hoping it couldn't... darn! – Borgleader Aug 03 '18 at 17:59

score 7 · Answer 2 · answered Oct 22 '17 at 14:29

7

It's not authoritative, but cppreference's entry for std::memcmp suggests that the padding bytes may differ:

memcmp() between two objects of type struct{char c; int n;} will compare the padding bytes whose values may differ when the values of c and n are the same

answered Oct 22 '17 at 14:29

Tristan Brindle

16,281
4
39
82

12

Not sure what this has to do with copying? – geometrian Oct 22 '17 at 16:03

score 6 · Answer 3 · answered Oct 22 '17 at 15:16

given that you asked about a POD type ( hence including unions ) it's worth mentioning that according to [class.copy]

The implicitly-defined copy/move constructor for a union X copies the object representation (6.9) of X

that for trivially copyable types should include padding bits as well. So, it could be just a matter of replacing A with

union A{ struct {
    char a;
    int b;
}; };

(actually, the above uses a non standard anonymous struct, but you get the point ... )

Relevant link: https://stackoverflow.com/questions/26241397/difference-between-object-and-value-representation-by-example — MSalters, Oct 22 '17 at 20:38

score 4 · Answer 4 · answered Oct 22 '17 at 14:45

Answering your second question:

Equivalently, if I transfer the underlying bytes of some A objects to another program that does not understand their meaning or structure, and treats them as an array of 8 bytes, can that other program safely compare two As for equality?

As an object of your type may contain padding bytes, another program generally can not compare two such objects for equality:

Knowing which bits of the bytes that make out the object semantically is the key for defining its value representation. However, in this scenario, the target program only knows the object representation, i.e. the sequence of bytes representing such an object in memory, including padding bytes. A function like memcmp can only compare such objects whose value representation is identical to its object representation in a meaningful way. If you use it to compare objects value-wise even though they have padding, it may fail to give the right results as it cannot tell which bits in the object representation are irrelevant for the value representations of two objects to be equal.

See http://en.cppreference.com/w/cpp/language/object

Do the padding bytes of a POD type get copied?

4 Answers4

Linked