https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64814
--- Comment #9 from Anquietas ---
(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 5011
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64814
--- Comment #6 from Anquietas ---
(In reply to Anquietas from comment #5)
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4296.pdf
The working copy for C++14, page 902 has the same specification as the other
PDF.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64814
--- Comment #5 from Anquietas ---
(In reply to Jonathan Wakely from comment #3)
> However, I don't see any requirement in the standard that says we're
> supposed to do so. All that is required is n assignments, there is no
> guarantee that the in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64814
--- Comment #2 from Anquietas ---
(In reply to Jonathan Wakely from comment #1)
> The problem is that increments to the input iterator happen inside
> the copy_n call, to a copy of the iterator not to readIter itself.
The copy_n implementation I
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: alex-j-a at hotmail dot co.uk
Bug 50119 is related. The issue should be clear from the example below; I've
confirmed the output on several web-based compilers (I'
