[committed] libstdc++: Make self-move well-defined for containers [PR 85828]

[Jonathan Wakely]

On 12/08/20 20:37 +0100, Jonathan Wakely wrote:
>The C++ LWG recently confirmed that self-move assignment should not have
>undefined behaviour for standard containers (see the proposed resolution
>of LWG 2839). The result should be a valid but unspecified value, just
>like other times when a container is moved from.
>
>Our std::list, std::__cxx11::basic_string and unordered containers all
>have bugs which result in undefined behaviour.
>
>For std::list the problem is that we clear the previous contents using
>_M_clear() instead of clear(). This means the _M_next, _M_prev and
>_M_size members are not zeroed, and so after we "update" them (with
>their existing values), we are left with dangling pointers and a
>non-zero size, but no elements.
>
>For the unordered containers the problem is similar. _Hashtable first
>deallocates the existing contents, then takes ownership of the pointers
>from the RHS object (which has just had its contents deallocated so the
>pointers are dangling).
>
>For std::basic_string it's a little more subtle. When the string is
>local (i.e. fits in the SSO buffer) we use char_traits::copy to copy the
>contents from this->data() to __rhs.data(). When &__rhs == this that

Oops, that's backwards. We copy from __rhs.data() to this->data().