[BUG] valarray_copy, with mask_array, libstdc++-v3

[Luke Kenneth Casson Leighton]

okay, i've established what the issues are.  the following
two code fragments - variations on the same function - 
do NOT contain bugs.  they both work.

i'm not sure which one is more efficient :)


// big number add.
bigint<_Tp>& operator +=(bigint<_Tp> &x)
{
	valarray<_Tp>::operator += (x); // do the add
	valarray< bool > c = get_carry(); // obtain an array of carrys

	// spanning from carry-gen to carry-term, add "one"
	valarray< bool > active = spanright(c, !c && (*this != max_val), 0);
	
	// now add one, where carry is required (active).
	valarray< _Tp > one(size()); // create an array of ones.
	one[active] = 1;
	valarray<_Tp>::operator += (one); // do the add of 1
	return *this;
}


// big number add.
bigint<_Tp>& operator +=(bigint<_Tp> &x)
{
	valarray<_Tp>::operator += (x); // do the add
	valarray< bool > c = get_carry(); // obtain an array of carrys

	// spanning from carry-gen to carry-term, add "one"
	valarray< bool > active = spanright(c, !c && (*this != max_val), 0);
	
	// now add one, where carry is required (active).
	valarray< _Tp > one(size()); // create an array of ones.
	one = 1;
	valarray<_Tp>::operator[](active) += one[active]; // do the add of 1
	return *this;
}

to reproduce the "bug":

	valarray<_Tp>::operator[](active) += one; // do the add of 1
	                         ^^^^^^^ len of 2
							             ^^^^ len of 4

so, it turns out to be a usage issue after all.

the intermediate mask_array created by the operator[](valarray<bool> &m)
function, at line 432, is of size 2 (in the test example i am using).

the size() of the array is 4.

the boolean one array is of size 4.

in the bug-example (valarray<_Tp>::operator[](active) += one),
the += operator goes through some weird contortions, ending up at
line 60 in valarray_meta.tcc, copying an intermediate result
(returned from the += contortions) of length 4 over the "active"
elements, of length 2.

hence the problem.

by restricting the boolean array _also_ to length 2
(valarray<_Tp>::operator[](active) += one[active])
the problem is avoided.


now.

would you like me to volunteer my time, as mentioned in an earlier
email, to create a base class that is used by both valarray and
_Array, which contains an _M_data _and_ and _M_size?

an assertion thrown by the valarray_copy because the size _M_size
did not match the size _Array._M_size would have been of great
value, here.

l.

[offtopic from hereon:

and please - mr elliston, responding to issues without
questions, in a "this is the end-of-discussion, go away -
read the spec, Do Not Bother Me Again, I Have Spoken" manner,
is really very insulting, and also a very _subtle_ way to be
insulting, and is a sure-fired 100% guaranteed way to drive
me absolutely up the wall and off the rails.

even just _one_ simple question "can you be more specific?",
from mr reis, made me happy.

it implied that he was expecting to receive a response - that
he was prepared to spend more time investigating, even though
he doesn't do libstdc++, which, given the surrounding context,
is extremely generous of him.

so, to mr reis' one simple question, instead of going up the
wall, i went and actually _looked_ at the problem again.

so, please, mr elliston, _don't_ do that again, i'm unstable
enough as it is without you compounding the issues.  ]