[BUG] valarray_copy mask_array-related over-run

Luke Kenneth Casson Leighton lkcl@samba-tng.org
Wed Jul 3 15:21:00 GMT 2002

--- /usr/include/g++-3/std/std_valarray.h	Wed Jul  3 21:49:02 2002
+++ /tmp/x	Wed Jul  3 21:49:08 2002
@@ -374,7 +374,7 @@
 valarray<_Tp>::operator= (const mask_array<_Tp>& __ma)
     __valarray_copy (__ma._M_array, __ma._M_mask,
-                     _Array<_Tp>(_M_data), _M_size);
+                     _Array<_Tp>(_M_data), __ma._M_sz);
     return *this;
when used as follows:

valarray<bool> b(4);

b[0] = false;
b[1] = true;
b[2] = true;
b[3] = false;

valarray<int> i(4);

i = 99;

i = i[b];

the number of items copied due to the assignment
of the mask_array created by the operator[] is FOUR.

_NOT_ two.

actually, it's a heck of a lot more than four, because
the loop starting at line 56 of valarray_meta.tcc over-runs
looking for (4-2) more randomly-set bools that are true,
in uninitialised memory.  __p gets advanced well into
trash memory.

the only reason i noticed this is because i was using a
rather complex class of
and it obviously attempted to create a copy constructor
from a complete garbage memory address of 0x101 as it
advanced __p too far down the array.

[it's for an emulator of a parallel processor version of
valarray, where the parallel processor is a 4096 one-bit-serial
monster.  therefore i need to emulate N-bit addition and
therefore parallel N-bit addition :) :)]


is this an already-discovered bug?

am i correct in the usage of this code?

please confirm, bug or no.

also appreciated acknowledgement of msg received.


p.s. patches accepted to get valarray and valarray_meta to
use a common array class containing _M_data and _M_size?
there is a lot of duplicated code between the two.

i need to be able to easily patch in a different memory
model, and at the moment i will have to patch it in
in _two_ separate places, it's a bit of a mess.

this message is private, confidential, and is intented for
the specified recipients only.  if you received in error,
altered, deleted, modified, destroyed or interfered with
the contents of this message, in whole or in part, please
inform the sender (that's me), immediately.

if you, the recipient, reply to this message, and do not
then receive a response, please consider your reply to have
been lost or deliberately destroyed: i *always* acknowledge
personal email received.  please therefore take appropriate
action and use appropriate protocols to ensure effective

thank you.

More information about the Libstdc++ mailing list