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`:

- the provided iterators satisfy the `InputIterator` requirements (25.3.5.3 [input.iterators])

- if an exception is thrown during the algorithm then there are no effects

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 propagate there 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.