[Bug libstdc++/64814] std::copy_n advances InputIterator one *less* time than necessary.

[alex-j-a at hotmail dot co.uk]

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.