Re: slice valarrays with std::string -> segfault

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

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