Does memcpy preserve data between different types?

Question

Does calling memcpy on two different structures preserve the original data if the buffer size is sufficient? And is it defined to retrieve values of another data type with data of previous data type if their respective data types overlap?

This should be similar for both c/cpp languages but I'm providing an example in cpp -

#include <iostream>
#include <cstring>

using namespace std;

struct A{
  int a;
  char b[10];
};

struct B{
  int ba;
  int bb;
};

int main(){
    B tmp;
    tmp.ba = 50;
    tmp.bb = 24;
    cout << tmp.ba << tmp.bb << "\n";

    // everything is fine yet

    A obj;
    memcpy(&obj, &tmp, sizeof(tmp));

    // 1. is this valid?
    cout << obj.a << "\n";

    B newB;
    memcpy(&newB, &obj, sizeof(newB));

    // 2. Are these valid?
    cout << newB.ba << newB.bb << "\n";
}

In above example I've commented 1st and 2nd comment, are they valid and is data preserved if sufficient buffer area is provided? Can we do this portably?

The structure and other functions related to it are in C library but we'll use and compile it with c++.

`memcpy` neither knows nor cares about the data type. It copies the number of bytes you specify, whether or not the destination buffer is large enough. When the ranges overlap, the behaviour is *undefined* and `memmove` should be used. — Weather Vane, Feb 19 '17 at 16:35
`memcpy()` doesn't guarantee anything regarding underlying data types. — πάντα ῥεῖ, Feb 19 '17 at 16:35
C or C++? Those are two different languages with a completely different object model. — Kerrek SB, Feb 19 '17 at 16:36
@KerrekSB Library provided is written in C but we'll use it in c++and compile with c++ compiler. — , Feb 19 '17 at 16:37
@πάνταῥεῖ - There actually *are* some guarantees. Certainly in C, printing `obj.a` would be valid. — Martin Bonner supports Monica, Feb 19 '17 at 16:39
@πάνταῥεῖ : True, but replacing the iostream calls with printf would make it valid C, and the question is an interesting one. — Martin Bonner supports Monica, Feb 19 '17 at 16:59
`cout << obj.a << "\n";` is not valid because the `memcpy` ends `obj`'s lifetime by reusing its storage. If you remove that line, the rest of the code is probably valid, not 100% sure though. — Baum mit Augen, Feb 19 '17 at 17:11
@user6241591 to use C libraries from a C++ program, you should compile the library with a C compiler, and use the linker to combine parts — M.M, Feb 19 '17 at 23:23
@M.M I assumed that writing something other than a value of the correct type into the memory of some object counts as reusing the memory. — Baum mit Augen, Feb 19 '17 at 23:25
@BaummitAugen 'Reusing the memory' != 'ends the object's lifetime'. The latter requires a destructor call. — user207421, Feb 20 '17 at 00:14
@EJP *"The lifetime of an object of type T ends when if T is a class type with a non-trivial destructor (12.4), the destructor call starts, or the storage which the object occupies is reused or released."* 3.8/1 [basic.life] in N4141 is what I was referring to. Just explaining my rational here, it's possible my misinterpret that. — Baum mit Augen, Feb 20 '17 at 00:19
@BaummitAugen 'reused' in that context isn't what you thought of. — Abhinav Gauniyal, Feb 20 '17 at 11:49

M.M · Accepted Answer · 2017-02-20T10:00:00.910

The C++ Standard doesn't specify the behaviour of memcpy, other than deferring to the C Standard. (Perhaps to avoid tackling issues like this!). In the C Standard it's defined as being equivalent to a sequence of character type copies¹.

So it seems reasonable to treat memcpy(&obj, &tmp, sizeof(tmp)); as:

unsigned char *dst = (char *)&obj;
unsigned char *src = (char *)&tmp;
for (size_t i = 0; i != sizeof tmp; ++i)
    dst[i] = src[i];

and then use the C++ Standard to cover that code.

The issues now are:

Does &tmp, &obj actually give the address of the start of the object?
What about padding bytes in obj?
What about uninitialized padding bytes in tmp?
What happens to the values of sub-objects of obj?

Issue 1: Yes, this is covered by [class.mem]/19, since there are no base class subobjects (and it doesn't overload operator&).

Issue 2: I cannot find any text specifically covering this; but the example in the standard of copying a class-type object into a char buffer and back into the object, would not work if it were not permitted to write padding bytes.

Issue 3: In [dcl.init]/12 is some text that explicitly permits the use of the above code for uninitialized data; and the destination will contain indeterminate values. So if uninitialized padding bytes in the source are only mapped to uninitialized padding bytes in the destination, it's fine. But if they are mapped to sub-objects in the destination, then those objects will have indeterminate value.

Issue 4: There's no problem here, the strict aliasing rule permits objects to have some (or all) of their bytes overwritten through a character type expression. Accessing the object later will yield the value corresponding to the representation, with UB if it doesn't represent a value.

So, all in all, I think your specific example is OK, assuming sizeof(A) >= sizeof(B).

¹ In C, memcpy also preserves the effective type of the object. C++ has a different object model and there is no equivalent of this. So if you used similar code with a C compiler, you'd also need to observe the strict aliasing rule between the types in both objects.

about 3rd point, this should also support your argument - http://en.cppreference.com/w/cpp/language/data_members#Standard_layout, right? — Abhinav Gauniyal, Feb 20 '17 at 09:07
@M.M if I `memset(..,0,..)` all structures before calling `memcpy()` this should solve uninitialized bits problem? — , Feb 20 '17 at 10:45
@M.M Does it mean that in [basic.types]/3 for a temporary buffer instead of `char buf[N]` one could use `int buf[...]` or `double buf[...]` or pretty much any allocated memory, assuming sufficient size? (And UB might happen only if we try to access the messed up and indeterminate `buf` data later.) — AlexD, Feb 21 '17 at 01:41
@AlexD I think so. There's probably some reason why non-standard-layout types could not be used but I'm not sure what the relevant standard clause is — M.M, Feb 21 '17 at 01:46

Does memcpy preserve data between different types?

1 Answers1

Linked