This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: slice valarrays with std::string -> segfault
- From: Gabriel Dos Reis <gdr at integrable-solutions dot net>
- To: Paolo Carlini <pcarlini at suse dot de>
- Cc: Jhair Tocancipa Triana <jhair_tocancipa at gmx dot net>, libstdc++ <libstdc++ at gcc dot gnu dot org>
- Date: 11 Dec 2005 00:15:18 +0100
- Subject: Re: slice valarrays with std::string -> segfault
- References: <87irtx8bcr.fsf@mandala.my-fqdn.de> <439B34F2.4000808@suse.de> <439B3B77.1060807@suse.de> <439B483A.80607@suse.de>
Paolo Carlini <pcarlini@suse.de> writes:
| Paolo Carlini wrote:
|
| >Gaby, I see __valarray_copy used (instead of __valarray_copy_construct)
| >by the conversion constructor from slice_array for any type T: i.e., no
| >placement new, that cannot possibly work a T such as 'struct element' in
| >the posted snippet. Indeed, lots and lots of errors from valgrind...
| >
| >
| Just to explain concretely what I mean, the attached quick and dirty
| hack avoids the Seg fault and makes valgrind happy. I think it tells us
| something...
I just saw this message. As said in previous mails, your analysis is
correct that the use of _copy instead of _copy_construct was
thoughtless -- other constructors carefully use _copy_construct.
[...]
| + __valarray_construct(_Array<_Tp> __a, size_t __n, size_t __s, _Array<_Tp> __b)
Can we do without this additional layer?
Otherwise, the patch is correct with that change.
Thanks!
-- Gaby