This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Open status.

### 2115. Undefined behaviour for `valarray` assignments with `mask_array` index?

Section: 28.6.8 [template.mask.array] Status: Open Submitter: Thomas Plum Opened: 2011-12-10 Last modified: 2016-01-28

Priority: 4

View all issues with Open status.

Discussion:

Recently I received a Service Request (SR) alleging that one of our testcases causes an undefined behavior. The complaint is that 28.6.8 [template.mask.array] in C++11 (and the corresponding subclause in C++03) are interpreted by some people to require that in an assignment "`a[mask] = b`", the subscript `mask` and the rhs `b` must have the same number of elements.

IMHO, if that is the intended requirement, it should be stated explicitly.

In any event, there is a tiny editorial cleanup that could be made:

In C++11, 28.6.8.1 [template.mask.array.overview] para 2 mentions

> "the expression `a[mask] = b;`"

but the semicolon cannot be part of an expression. The correction could omit the semicolon, or change the word "expression" to "assignment" or "statement".

Here is the text of the SR, slightly modified for publication:

> Subject: SR01174 LVS _26322Y31 has undefined behavior [open]

> [Client:]
> The test case t263.dir/_26322Y31.cpp seems to be illegal as it has an undefined behaviour. I searched into the SRs but found SRs were not related to the topic explained in this mail (SR00324, SR00595, SR00838).

> >     const char vl[] = {"abcdefghijklmnopqrstuvwxyz"};
> >     const char vu[] = {"ABCDEFGHIJKLMNOPQRSTUVWXYZ"};
> >     const std::valarray<char> v0(vl, 27), vm5(vu, 5), vm6(vu, 6);
> >     std::valarray<char> x = v0;
> >     […]
> >     const bool vb[] = {false, false, true, true, false, true};
> >     const std::valarray<bool> vmask(vb, 6);
> >     x = v0;
> >     x[vmask] = vm5;      // ***** HERE....
> >     steq(&x[0], "abABeCghijklmnopqrstuvwxyz");
> >     x2 = x[vmask];       // ***** ....AND HERE
> >     […]

> This problem has already been discussed between [experts]: See thread http://gcc.gnu.org/ml/libstdc++/2009-11/threads.html#00051 Conclusion http://gcc.gnu.org/ml/libstdc++/2009-11/msg00099.html

> [Plum Hall:]
> Before I log this as an SR, I need to check one detail with you.

> I did read the email thread you mentioned, and I did find a citation (see INCITS ISO/IEC 14882-2003 Section 26.3.2.6 on valarray computed assignments):

> Quote: "If the array and the argument array do not have the same length, the behavior is undefined",

> But this applies to computed assignment (`*=`, `+=`, etc), not to simple assignment. Here is the C++03 citation re simple assignment:

> 26.3.2.2 valarray assignment [lib.valarray.assign]

> >     valarray<T>& operator=(const valarray<T>&);

> > > 1 Each element of the `*this` array is assigned the value of the corresponding element of the argument array. The resulting behavior is undefined if the length of the argument array is not equal to the length of the `*this` array.

> In the new C++11 (N3291), we find ...

> 26.6.2.3 valarray assignment [valarray.assign]

> >     valarray<T>& operator=(const valarray<T>& v);

> > > 1 Each element of the `*this` array is assigned the value of the corresponding element of the argument array. If the length of `v` is not equal to the length of `*this`, resizes `*this` to make the two arrays the same length, as if by calling `resize(v.size())`, before performing the assignment.

> So it looks like the testcase might be valid for C++11 but not for C++03; what do you think?

> [Client:]
> I quite agree with you but the two problems I mentioned:

> >     x[vmask] = vm5;      // ***** HERE....
> >     […]
> >     x2 = x[vmask];       // ***** ....AND HERE

> refer to `mask_array` assignment hence target the C++03 26.3.8 paragraph. Correct?

> [Plum Hall:]
> I mentioned the contrast between C++03 26.3.2.2 para 1 versus C++11 26.6.2.3 para 1.

> But in C++03 26.3.8, I don't find any corresponding restriction. Could you quote the specific requirement you're writing about?

> [Client:]
> I do notice the difference between c++03 26.3.2.2 and c++11 26.6.2.3 about assignments between different sized `valarray` and I perfectly agree with you.

> But, as already stated, this is not a simple `valarray` assignment but a `mask_array` assignment (c++03 26.3.8 / c++11 26.6.8). See c++11 quote below:

> 26.6.8 Class template mask_array
> 26.6.8.1 Class template mask_array overview
> [....]

> 1. This template is a helper template used by the mask subscript operator: `mask_array<T> valarray<T>::operator[](const valarray<bool>&)`.

> 2. It has reference semantics to a subset of an array specified by a boolean mask. Thus, the expression `a[mask] = b;` has the effect of assigning the elements of `b` to the masked elements in `a` (those for which the corresponding element in `mask` is true.)

> 26.6.8.2 mask_array assignment

> >     void operator=(const valarray<T>&) const;
> >     const mask_array& operator=(const mask_array&) const;

> > > 1 These assignment operators have reference semantics, assigning the values of the argument array elements to selected elements of the `valarray<T>` object to which it refers.

> In particular, [one of the WG21 experts] insisted on the piece "the elements of `b`".

> That is why I reported the test t263.dir/_26322Y31.cpp having an undefined behaviour.

> [Plum Hall:]
> OK, I can see that I will have to ask WG21; I will file an appropriate issue with the Library subgroup. In the meantime, I will mark this testcase as "DISPUTED" so that it is not required for conformance testing, until we get a definitive opinion.

[2012, Kona]

Moved to Open.

There appears to be a real need for clarification in the standard, and implementations differ in their current interpretation. This will need some research by implementers and a proposed resolution before further discussion is likely to be fruitful.

Proposed resolution: