On Thu, May 11, 2017 at 12:23 PM, Martin Sebor <mse...@gmail.com> wrote: > The challenge with using memcpy or memset with class types is > figuring out if it's being called to copy-construct a new object > or assign a new value to an existing one. In general it's not > possible to tell so the conservative assumption is that it's > the latter. > > Because of that, relying on the trivially copyable property to > determine whether it's safe to assign a new value to an object > is not sufficient (or even necessary). The class must be at > a minimum trivially assignable. But it turns out that even > trivial assignability as defined by C++ isn't enough. A class > with a const data member or a member of a reference type is > considered "trivially assignable" but its copy assignment is > deleted, and so it can't be assigned to. Calling memset or > memcpy to write over an object of such a class can violate > the const invariant or corrupt the reference, respectively.
Yes, "trivially copyable" elides the differences between initialization and assignment context. I agree that it makes sense to check for a trivial assignment operator specifically. I guess we want a slightly stronger "trivially copyable" that also requires a non-deleted assignment operator. It seems to me that the relevant tests are: bcopy/memcpy/memmove want trivally copyable + non-deleted assignment. bzero/memset want trivial + non-deleted assignment. I'm still not convinced we need to consider standard-layout at all. Jason
