This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: libstdc++: Problems with gslices (patch included)
- To: Peter Schmid <schmid at snake dot iap dot physik dot tu-darmstadt dot de>
- Subject: Re: libstdc++: Problems with gslices (patch included)
- From: Gabriel Dos Reis <gdr at codesourcery dot com>
- Date: 11 Feb 2001 07:33:11 +0100
- Cc: gcc-patches at gcc dot gnu dot org, libstdc++ at gcc dot gnu dot org
- Organization: CodeSourcery, LLC
- References: <Pine.LNX.4.21.0101271658270.23274-100000@snake.iap.physik.tu-darmstadt.de>
Peter Schmid <schmid@snake.iap.physik.tu-darmstadt.de> writes:
| When running the following program tgs compiled by g++-20010125 on
| i686-pc-linux-gnu
[...]
| incorrect output is obtained.
| ./tgs
| abcdefghijklmnop
| ABCDEF
| abcAeCBEDjFlmnop
| abcdefghijklmnop
| dgfihkjmlon
| cfilo
|
| Closer examination shows that the arguments of len and str in the
| gslice implementation seem to be reversed.
Your analysis is correct,
from gslice.h:
inline
gslice::gslice(size_t __o, const valarray<size_t>& __l,
const valarray<size_t>& __s)
: _M_index(new gslice::_Indexer(__o, __l, __s)) {}
from valarray-inst.cc:
gslice::_Indexer::_Indexer(size_t __o, const valarray<size_t>& __s,
const valarray<size_t>& __l)
which clearly shows that the arguments were reversed in the last
case.
Thanks for your feedback. Fixed with fortcoming patch.
-- Gaby
CodeSourcery, LLC http://www.codesourcery.com