“constructing” a trivially-copyable object with memcpy

by

This is unspecified which is supported by N3751: Object Lifetime, Low-level Programming, and
memcpy which says amongst other things:

The C++ standards is currently silent on whether the use of memcpy to
copy object representation bytes is conceptually an assignment or an
object construction. The difference does matter for semantics-based
program analysis and transformation tools, as well as optimizers,
tracking object lifetime. This paper suggests that

  1. uses of memcpy to copy the bytes of two distinct objects of two different trivial copyable tables (but otherwise of the same size) be
    allowed

  2. such uses are recognized as initialization, or more generally as (conceptually) object construction.

Recognition as object construction will support binary IO, while still
permitting lifetime-based analyses and optimizers.

I can not find any meeting minutes that has this paper discussed, so it seems like it is still an open issue.

The C++14 draft standard currently says in 1.8 [intro.object]:

[…]An object is created by a definition (3.1), by a new-expression
(5.3.4) or by the implementation (12.2) when needed.[…]

which we don’t have with the malloc and the cases covered in the standard for copying trivial copyable types seem to only refer to already existing objects in section 3.9 [basic.types]:

For any object (other than a base-class subobject) of trivially
copyable type T, whether or not the object holds a valid value of type
T, the underlying bytes (1.7) making up the object can be copied into
an array of char or unsigned char.42 If the content of the array of
char or unsigned char is copied back into the object, the object shall
subsequently hold its original value[…]

and:

For any trivially copyable type T, if two pointers to T point to
distinct T objects obj1 and obj2, where neither obj1 nor obj2 is a
base-class subobject, if the underlying bytes (1.7) making up obj1 are
copied into obj2,43 obj2 shall subsequently hold the same value as
obj1.[…]

which is basically what the proposal says, so that should not be surprising.

dyp points out a fascinating discussion on this topic from the ub mailing list: [ub] Type punning to avoid copying.

Propoal p0593: Implicit creation of objects for low-level object manipulation

The proposal p0593 attempts to solve this issues but AFAIK has not been reviewed yet.

This paper proposes that objects of sufficiently trivial types be created on-demand as necessary within newly-allocated storage to give programs defined behavior.

It has some motivating examples which are similar in nature including a current std::vector implementation which currently has undefined behavior.

It proposes the following ways to implicitly create an object:

We propose that at minimum the following operations be specified as implicitly creating objects:

  • Creation of an array of char, unsigned char, or std::byte implicitly creates objects within that array.

  • A call to malloc, calloc, realloc, or any function named operator new or operator new[] implicitly creates objects in its returned storage.

  • std::allocator::allocate likewise implicitly creates objects in its returned storage; the allocator requirements should require other allocator implementations to do the same.

  • A call to memmove behaves as if it

    • copies the source storage to a temporary area

    • implicitly creates objects in the destination storage, and then

    • copies the temporary storage to the destination storage.

    This permits memmove to preserve the types of trivially-copyable objects, or to be used to reinterpret a byte representation of one object as that of another object.

  • A call to memcpy behaves the same as a call to memmove except that it introduces an overlap restriction between the source and destination.

  • A class member access that nominates a union member triggers implicit object creation within the storage occupied by the union member. Note that this is not an entirely new rule: this permission already existed in [P0137R1] for cases where the member access is on the left side of an assignment, but is now generalized as part of this new framework. As explained below, this does not permit type punning through unions; rather, it merely permits the active union member to be changed by a class member access expression.

  • A new barrier operation (distinct from std::launder, which does not create objects) should be introduced to the standard library, with semantics equivalent to a memmove with the same source and destination storage. As a strawman, we suggest:

    // Requires: [start, (char*)start + length) denotes a region of allocated
// storage that is a subset of the region of storage reachable through start.
// Effects: implicitly creates objects within the denoted region.
void std::bless(void *start, size_t length);

In addition to the above, an implementation-defined set of non-stasndard memory allocation and mapping functions, such as mmap on POSIX systems and VirtualAlloc on Windows systems, should be specified as implicitly creating objects.

Note that a pointer reinterpret_cast is not considered sufficient to trigger implicit object creation.

More Related Contents:

  1. A positive lambda: ‘+[]{}’ – What sorcery is this? [duplicate]
  2. Take the address of a one-past-the-end array element via subscript: legal by the C++ Standard or not?
  3. Lifetime of temporaries
  4. Why would the behavior of std::memcpy be undefined for objects that are not TriviallyCopyable?
  5. Why class data members can’t be initialized by direct initialization syntax?
  6. Is adding to a “char *” pointer UB, when it doesn’t actually point to a char array?
  7. Efficient unsigned-to-signed cast avoiding implementation-defined behavior
  8. Is a pointer with the right address and type still always a valid pointer since C++17?
  9. Floating point comparison revisited
  10. Does not evaluating the expression to which sizeof is applied make it legal to dereference a null or invalid pointer inside sizeof in C++?
  11. In C++11, does `i += ++i + 1` exhibit undefined behavior?
  12. Pure virtual functions may not have an inline definition. Why?
  13. What does the void() in decltype(void()) mean exactly?
  14. Are non dereferenced iterators past the “one past-the-end” iterator of an array undefined behavior?
  15. Can the point-of-instantiation be delayed until the end of the translation unit?
  16. When instantiating a template, should members of its incomplete argument types be visible?
  17. Is most vexing parse a formally defined concept
  18. Pseudo-destructor call does not destroy an object
  19. Why is a constexpr function on a reference not constexpr?
  20. Will consteval functions allow template parameters dependent on function arguments?
  21. How can an incomplete type be used as a template parameter to vector here?
  22. Is the Empty Base Class Optimization now a mandatory optimization (at least for standard-layout classes)?
  23. Classes with both template and non-template conversion operators in the condition of switch statement
  24. Is it allowed for a compiler to optimize away a local volatile variable?
  25. What is the difference between std::quick_exit and std::abort and why was std::quick_exit needed?
  26. Why is `make_unique` disallowed?
  27. Does C++11 change the behavior of explicitly calling std::swap to ensure ADL-located swap’s are found, like boost::swap?
  28. Using std::bind with member function, use object pointer or not for this argument?
  29. Why don’t I need to specify “typename” before a dependent type in C++20?
  30. memcpy/memmove to a union member, does this set the ‘active’ member?

Leave a Comment