https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64814
--- Comment #9 from Anquietas <alex-j-a at hotmail dot co.uk> --- (In reply to Jonathan Wakely from comment #8) > N.B. libc++ changed its copy_n with > http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20110221/039404. > html and then libstdc++ did the same in PR 50119 I linked that bug report in the OP, but as it happens the behaviour is quite interesting with std::istream_iterator<int> using an adaptation of the code I pasted in OP: int main() { std::istringstream ss("1 2 3 4 5 6 7 8 9 0 1 2 "); std::vector<int> output; auto readIter = std::istream_iterator<int>(ss); for (int i = 0; i < 3; ++i) { output.clear(); auto inserter = std::back_inserter(output); // Doesn't work - outputs 123415671890 std::copy_n(readIter, 4, inserter); for (auto n : output) std::cout << n; } } However, in this case moving readIter's declaration inside the loop fixes it. If we go back to the code in OP and do the same, it *doesn't* fix it and still produces the same output in either case. At the very least, the current implementation of copy_n appears to be inconsistent, depending on the type of iterator used. The implementation I provided for copy_n in OP doesn't work for the istream_iterator case though, and neither does the direct for loop approach.
