slice valarrays with std::string -> segfault
Gabriel Dos Reis
gdr@integrable-solutions.net
Sat Dec 10 22:57:00 GMT 2005
Paolo Carlini <pcarlini@suse.de> writes:
| 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...
The following uses of __valarray_copy_construct are correct:
* valarray<T>::valarray(const T*)
* valarray<T>::valarray(const valarray<T>&)
The following uses of __valarray_copy are wrong:
* valarray<T>::valarray(const slice_array<T>&)
* valarray<T>::valarray(const gslice_array<T>&)
* valarray<T>::valarray(const mask_array<T>&)
* valarray<T>::valarray(const indirect_array<T>&)
* valarray<T>::valarray(const _Expr<>&);
| 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).
I see. I'm just back to home; I'll try to cook some patch -- given
the time in EU :-)
Thanks,
-- Gaby
More information about the Libstdc++
mailing list