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: Paolo Carlini <pcarlini at suse dot de>
- To: Gabriel Dos Reis <gdr at integrable-solutions dot net>
- Cc: Jhair Tocancipa Triana <jhair_tocancipa at gmx dot net>, libstdc++ <libstdc++ at gcc dot gnu dot org>
- Date: Sat, 10 Dec 2005 23:31:17 +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> <m33bl0sfw9.fsf@uniton.integrable-solutions.net>
Gabriel Dos Reis wrote:
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.
Ok, thanks.
[...]
| + __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.
Really, I have to spend some serious time on the issue. Right now I'm
missing a lot of important details. Maybe you can guide me a bit?
For example, I see the other conversion constructors (both
standard-mandated and not, i.e., from gslice_array, mask_array,
indirect_array, _Expr<>) also calling __valarray_copy... I'm afraid
something can go wrong there too, but I don't know sufficiently well
<valarray> to tell for sure, at the moment...
As regards avoiding the additional layer, in principle seems certainly
feasible, I was quickly mimicking what currently happens when
__valarray_copy is used (i.e., those intermediate templates around 2/3
of valarray_array.h).
Paolo.