[[patch] valarray (was Re: valarray_copy implementation question)

[Christian BRUEL]

 > This disposition makes your example above have an undefined behaviour.

this : myarray[mymask] += valarray<int>(3,n);

is undefined ???
with
myarray = size 10
valrarray = size 10
mymask = size 10, 2 true bits.

oh well...

I've recorded the original bug
at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42182

Many thanks

Christian

Gabriel Dos Reis wrote:
> 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
>