This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of C++20 status.

3054. uninitialized_copy appears to not be able to meet its exception-safety guarantee

Section: 27.11.5 [uninitialized.copy] Status: C++20 Submitter: Jon Cohen Opened: 2018-01-24 Last modified: 2021-02-25

Priority: 2

View all other issues in [uninitialized.copy].

View all issues with C++20 status.

Discussion:

I believe that uninitialized_copy is unable to meet its exception-safety guarantee in the presence of throwing move constructors:

27.11 [specialized.algorithms]/1 has two statements of note for the specialized algorithms such as uninitialized_copy:

Suppose we have an input iterator Iter. Then std::move_iterator<Iter> appears to also be an input iterator. Notably, it still satisfies that (void)*a, *a is equivalent to *a for move iterator a since the dereference only forms an rvalue reference, it doesn't actually perform the move operation (25.3.5.3 [input.iterators] Table 95 — "Input iterator requirements").

Suppose also that we have a type T whose move constructor can throw, a range of T's [tbegin, tend), and a pointer to an uninitialized buffer of T's buf. Then std::uninitialized_copy(std::make_move_iterator(tbegin), std::make_move_iterator(tend), buf) can't possibly satisfy the property that it has no effects if one of the moves throws — we'll have a T left in a moved-from state with no way of recovering.

See here for an example in code.

It seems like the correct specification for uninitialized_copy should be that if InputIterator's operator* returns an rvalue reference and InputIterator::value_type's move constructor is not marked noexcept, then uninitialized_copy will leave the objects in the underlying range in a valid but unspecified state.

[2018-01-24, Casey comments and provides wording]

This issue points out a particular hole in the "..if an exception is thrown in the following algorithms there are no effects." wording for the "uninitialized" memory algorithms (27.11 [specialized.algorithms]/1) and suggests a PR to patch over said hole. The true problem here is that "no effects" is not and never has been implementable. For example, "first != last" may have observable effects that an implementation is required to somehow reverse if some later operation throws an exception.

Rather than finding problem case after problem case and applying individual patches, we should fix the root cause. If we alter the problematic sentence from [specialized.algorithms]/1 we can fix the issue once and for all and have implementable algorithms.

[2018-02-05, Priority set to 2 after mailing list discussion]

[2018-06 Rapperswil Thursday issues processing]

Status to Ready

[2018-11, Adopted in San Diego]

Proposed resolution:

This wording is relative to N4713.

  1. Modify 27.11 [specialized.algorithms] as indicated:

    -1- […]

    Unless otherwise specified, if an exception is thrown in the following algorithms objects constructed by a placement new-expression (7.6.2.8 [expr.new]) are destroyed in an unspecified order before allowing the exception to propagatethere are no effects.

  2. Modify 27.11.6 [uninitialized.move] as indicated (The removed paragraphs are now unnecessary):

    template<class InputIterator, class ForwardIterator>
  ForwardIterator uninitialized_move(InputIterator first, InputIterator last,
                                     ForwardIterator result);

    […]

    -2- Remarks: If an exception is thrown, some objects in the range [first, last) are left in a valid but unspecified state. 

    template<class InputIterator, class Size, class ForwardIterator>
  pair<InputIterator, ForwardIterator>
    uninitialized_move_n(InputIterator first, Size n, ForwardIterator result);

    […]

    -4- Remarks: If an exception is thrown, some objects in the range [first, std::next(first, n)) are left in a valid but unspecified state.