This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: serious bug in libstdc++-3.2 std::copy?
- From: Phil Edwards <phil at jaj dot com>
- To: "Neal D. Becker" <nbecker at hns dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Wed, 4 Dec 2002 11:49:05 -0500
- Subject: Re: serious bug in libstdc++-3.2 std::copy?
- References: <x884r9tycmn.fsf@rpppc1.md.hns.com>
On Wed, Dec 04, 2002 at 11:25:52AM -0500, Neal D. Becker wrote:
> I am copying from a custom container (RingBuffer) to a vector. The
> RingBuffer has a special iterator. I use std::copy. I get a
> segfault. GDB tells me:
[...]
>
> 3. inline _OutputIter
> __copy_ni2(_InputIter __first, _InputIter __last,
> _OutputIter __result, __true_type)
>
> OK, output is normal
>
> 4. template<typename _Tp>
> inline _Tp*
> __copy_aux2(_Tp* __first, _Tp* __last,
> _Tp* __result, __true_type)
>
> OK, type has trivial assign (in this case it is int)
If the input iterator does not have pointer-type semantics, then this
is where things have gone wrong. The first/last parameters are already
assumed to be Tp*'s here.
#3 -> #4 could only happen the way you show here if both the input iterators
and the (underlying) output iterator can all de deduced to be pointing to
the same type. Are RingBuffer's iterators pointer types?
Phil
--
I would therefore like to posit that computing's central challenge, viz. "How
not to make a mess of it," has /not/ been met.
- Edsger Dijkstra, 1930-2002