Page History

Self-copy assignment can occur in situations of varying complexity, but all boil down to essentially, all self-copy assignments entail some variation of :the following.

#include <utility>
 
struct S { /* ... */ }
 
void f() {
  S s;
  s = s; // Self-copy-assignment
  s = std::move(s); // Self-move-assignment
}

User-provided copy and move assignment operators must properly handle self-copy assignment.

Copy Assignment

The post-conditions The postconditions required for copy assignment are specified by the C++ Standard, [utility.arg.requirements], Table 23 [ISO/IEC 14882-2014], which states that for x = y, the value of y is unchanged. When &x == &y, this post-condition postcondition translates into the values of both x and y remaining unchanged. A naive implementation of copy assignment will could destroy object-local resources in the process of copying resources from the given parameter. If the given parameter is the same object as the local object, the act of destroying object-local resources will invalidate them. The subsequent copy of those resources will be left in an indeterminate state, which violates the post-conditionpostcondition.

A user-provided copy assignment operator must prevent self-copy - assignment from leaving the object in an indeterminate state. This can be accomplished by self-assignment tests, copy-and-swap, or other idiomatic design patterns.Move Assignment

The post-conditions required for a move assignment are specified by the C++ Standard,   [utility.arg.requirements], Table 22, which states that for x = std::move(y), the value of y is left in a valid, but unspecified, state. When &x == &y, this post-condition translates into the values of both x and y remaining in a valid, but unspecified state. Leaving the values in an unspecified state may result in vulnerabilities leading to exploitable code.A user-provided move assignment operator must prevent self-move-assignment from leaving the object in a valid, but unspecified, state. Akin to copy assignment, this can be accomplished by self-assignment tests, move-and-swap, or other idiomatic design patternscopyassignable], specifies that types must ensure that self-copy assignment leave the object in a consistent state when passed to Standard Template Library (STL) functions. Since objects of STL types are used in contexts where CopyAssignable is required, STL types are required to gracefully handle self-copy assignment.

Noncompliant Code Example

In this noncompliant code example, the copy and move assignment operators do operator does not protect against self-copy assignment. If self-copy - assignment occurs, this->S1>s1 is deleted, which results in RHSrhs.S1s1 also being deleted. The invalidated memory for RHSrhs.S1s1 is then passed into the copy constructor for S, which can result in dereferencing an invalid pointer. If self-move-assignment occurs, it is dependent on the implementation of std::swap as to whether S1 is left in a valid, but unspecified, state.

#include <new>
#include <utility>
 
struct S { S(const S &) noexcept; /* ... */ };
 
class T {
  int Nn;
  S *S1s1;
 
public:
  T(const T &RHSrhs) : Nn(RHSrhs.Nn), S1s1(RHSrhs.S1s1 ? new S1S(*RHSrhs.S1s1) : nullptr) {}
  T(T &&RHS) : N(RHS.N), S1(RHS.S1) noexcept { RHS.S1 = nullptr; }
  ~T() { delete S1s1; }
 
  // ...
 
  T& operator=(const T &RHSrhs) {
    Nn = RHSrhs.Nn;
    delete S1s1;
    S1s1 = new S(*RHSrhs.S1s1);
    return *this;
  }
 
  T& operator==(T &&RHS) noexcept {
    N = RHS.N;
    std::swap(S1, RHS.S1);
    return *this;
  }
};

Compliant Solution (Self-Test)

This compliant solution guards against self-copy assignment by testing whether the given parameter is the same as this. If self-copy assignment occurs, the result of then operator= is a noop, otherwise  does nothing; otherwise, the copy and move proceeds as in the original example.

#include <new>
#include <utility>
 
struct S { S(const S &) noexcept; /* ... */ };
 
class T {
  int Nn;
  S *S1s1;
 
public:
  T(const T &RHSrhs) : Nn(RHSrhs.Nn), S1s1(RHSrhs.S1s1 ? new S1S(*RHSrhs.S1s1) : nullptr) {}
  T(T &&RHS) : N(RHS.N), S1(RHS.S1) noexcept { RHS.S1 = nullptr; }
  ~T() { delete S1s1; }

  // ...
 
  T& operator=(const T &RHSrhs) {
    if (this != &RHSrhs) {
      Nn = RHSrhs.Nn;
      delete S1s1;
      try {
        S1s1 = new S(*RHSrhs.S1s1);
      } catch (std::bad_alloc &) {
        S1s1 = nullptr; // For basic exception guarantees
        throw;
      }
    }
    return *this;
  }
 
  T& operator==(T &&RHS) noexcept {
    if (this != &RHS) {
      N = RHS.N;
      std::swap(S1, RHS.S1);
    }
    return *this;
  }
};

This Note that this solution does not provide a strong exception guarantee for the copy assignment. Specifically, if an exception is called when evaluating the new expression, this has already been modified. However, this solution does provide a basic exception guarantee because no resources are leaked and all data members contain valid values. Consequently, this code complies with ERR56-CPP. Guarantee exception safety.

Compliant Solution (Copy and Swap)

This compliant solution avoids self-copy -assignment by accepting the operator= parameter by value instead of by reference, which results in the copy constructor being called prior to entering the assignment operator. The assignment operator is then allowed to simply swap the contents of RHS and assignment by constructing a temporary object from rhs that is then swapped with *this. This compliant solution is able to provide provides a strong exception guarantee because the assignment operator swap() will never be called if resource allocation results in an exception being thrown . It avoids self-move-assignment by testing for self-assignment as in the previous compliant solutionwhile creating the temporary object.

#include <new>
#include <utility>
 
struct S { S(const S &) noexcept; /* ... */ };
 
class T {
  int Nn;
  S *S1s1;
 
public:
  T(const T &RHSrhs) : Nn(RHSrhs.Nn), S1s1(RHSrhs.S1s1 ? new S1S(*RHSrhs.S1s1) : nullptr) {}
  T(T &&RHS) : N(RHS.N), S1(RHS.S1) noexcept { RHS.S1 = nullptr; }
  ~T() { delete S1s1; }

  // ...
 
  friend void swap(T &LHS, T &RHSrhs) noexcept {
    using std::swap;
    swap(LHS.Nn, RHSrhs.Nn);
    swap(LHS.S1s1, RHSrhs.S1s1);
  }
 
  T& operator=(T RHSrhs) noexcept {
    rhs.swap(*this, RHS);
    return *this;
  }
 
  T& operator==};

Compliant Solution (Move and Swap)

This compliant solution uses the same classes S and T from the previous compliant solution, but adds the following public constructor and methods:

  T(T &&RHSrhs) noexcept {
    if ( *this != &RHS) {std::move(rhs); }

  // ... everything except N operator= RHS..N;
  

  T& operator=(T &&rhs) noexcept {
    using std::swap;
    swap(S1n, RHSrhs.S1n);
    }swap(s1, rhs.s1);
    return *this;
  }
};

Risk Assessment

The copy assignment operator uses std::move() rather than swap() to achieve safe self-assignment and a strong exception guarantee. The move assignment operator uses a move (via the method parameter) and swap.

The move constructor is not strictly necessary, but defining a move constructor along with a move assignment operator is conventional for classes that support move operations.

Note that unlike copy assignment operators, the signature of a move assignment operator accepts a non-const reference to its object with the expectation that the moved-from object will be left in an unspecified, but valid state. Move constructors have the same difference from copy constructors.

Risk Assessment

Allowing a copy assignment operator to corrupt an object could lead to undefined behaviorAllowing a copy assignment operator to corrupt an object could lead to undefined behavior. Allowing a move assignment operator to leave an object in a valid but unspecified state could lead to unexpected program execution.

Automated Detection

Related Vulnerabilities

Search for other vulnerabilities resulting from the violation of this rule on the CERT website.

Related Guidelines

Bibliography

This rule is a partial subset of OOP58-CPP. Copy operations must not mutate the source object when copy operations do not gracefully handle self-copy assignment, because the copy operation may mutate both the source and destination objects (due to them being the same object).

Bibliography

...

Image Added Image Added Image AddedMEM41-CPP. Declare a copy constructor, a copy assignment operator, and a destructor in a class that manages resources      08. Memory Management (MEM)      ERR40-CPP. Do not leak resources when handling exceptions