This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [[patch] valarray (was Re: valarray_copy implementation question)
On Thu, Nov 26, 2009 at 1:51 AM, Christian BRUEL <christian.bruel@st.com> wrote:
> Hello Paolo,
>
> First, a typo, in my example the assignment should have been
> myarray[mymask] += valarray<int>(3,n); ?// with n = 10 which is > as n true
> elements.
> (I'm reattaching it here with the correct size and removing the testsuite
> dependencies to make it standalone).
>
> So now, I think that your interpretation of the Standard is wrong when you
> write : ?"the source array is supposed to have exactly as many elements as
> the true booleans on the left side"
>
> that is an undefined behavior, (see INCITS ISO/IEC 14882-2003 Section
> 26.3.2.6 on valarray computed assigments):
> Quote: "If the array and the argument array do not have the same length, the
> behavior is undefined",
This disposition makes your example above have an undefined behaviour.
> if you consider the possibility than there are less n true elements than the
> size of the source array, which is the case here.
As I explained in an earlier message, you have to consider that at any
single point, the various xxx_array exist only to implement array
expressions. AND that in expression such as
dst_ary = src_ary
where both sides of '=' are array expressions, the above disposition applies.
>
> So now back to my example, when I do
>
> ?mymask[0] = true;
> ?mymask[9] = true;
>
> ?myarray[mymask] += valarray<int>(3,n)
Unless 'n' is equal to 2, that expression has undefined
behaviour.
>
> I really expects (myarray[0] == 4 and (myarray[9]) to be incremented, with
> myarray of size n=10 initialized with 1.
That expectation is unfounded.
>
> and your assignment proposals:
> myarray[mymask] += valarray<int>(3,0);
> myarray[mymask] += valarray<int>(3,2);
> are NOT guaranteed to work fine since you'd have the array to be of size 10
> and the argument array of size [0,2]. Note that the size of myarray is
> really 10, it's not the number of true elements that only determines the
> elements to which the operation will apply.
The size that matters here is that of 'myarray[mymask]'.
>
> But in anycase, the current trunk behavior of the testcase is Segmentation
> fault (compile with -O0) which is obviously wrong.
If you feed the library with data that violate its preconditions, you get
an undefined behaviour. I do not consider 'segmentation fault' as a wrong
undefined behaviour.
>
> Do we agree now ?
No.
-- Gaby