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

### 2471. `copy_n`'s number of `InputIterator` increments unspecified

Section: 27.7.1 [alg.copy] Status: Open Submitter: Jonathan Wakely Opened: 2015-01-28 Last modified: 2018-06-22

Priority: 3

View other active issues in [alg.copy].

View all other issues in [alg.copy].

View all issues with Open status.

Discussion:

It's unspecified how many times `copy_n` increments the `InputIterator`. `uninitialized_copy_n` is specified to increment it exactly `n` times, which means if an `istream_iterator` is used then the next character after those copied is read from the stream and then discarded, losing data.

I believe all three of Dinkumware, libc++ and libstdc++ implement `copy_n` with `n - 1` increments of the `InputIterator`, which avoids reading and discarding a character when used with `istream_iterator`, but is inconsistent with `uninitialized_copy_n` and causes surprising behaviour with `istreambuf_iterator` instead, because `copy_n(in, 2, copy_n(in, 2, out))` is not equivalent to `copy_n(in, 4, out)`

[2016-08 Chicago]

Tues PM: refer to LEWG

[LEWG Kona 2017]

This is a mess. Append to Effects: If the InputIterator is not a forward iterator, increments n-1 times. Otherwise the number of increments is not more than n. (ncm) The preceding proposition is unsatisfactory, because it is wrong for istreambuf_iterator, which is much more useful than istream_iterator. Proposing instead: Append to Effects: If InputIterator is istream_iterator for some T, increments n-1 times. Otherwise, increments n times. Want a paper exploring what the implementations actually do, and what non-uniformity is "right".

Status to Open

Proposed resolution: