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

[Luke Kenneth Casson Leighton <lkcl at samba-tng dot org>]

On Sat, Jul 06, 2002 at 10:32:31PM +0200, Gabriel Dos Reis wrote:

> Luke Kenneth Casson Leighton <lkcl@samba-tng.org> writes:
> 
> | dear sirs,
> | 
> | i noticed that code like this:
> | 
> | valarray<bool> b(4);
> | b[0] = false;
> | b[1] = true;
> | b[2] = true;
> | b[0] = false;

 [actually it should be b[3] = false, but it doesn't matter given
  that b is initialised to all zeros.  i hope! ]

> OK.
> 
> | valarray<int> i(4);
> 
> OK.  All elements in "i" have value zero.
> 
> | valarray<int> j;
> 
> "j" is empty.
 
 or, j is not actually declared here: see below for better
 example, or also see other earlier post.


> | i = 9;
> 
> All elements are set to 9.
> 
> | j = i[b];
> 
> What are you expecting from this one?

 j[0] = 0
 j[1] = 9
 j[2] = 9
 j[3] = 0


> | should create an array (j) of two items.

 ??? did i write this??  :)  i don't remember writing that! :)


> No.  There is no such requirement.  Actually that is undefined behaviour.

 
  .... ah... um... well, it's not, but it works, and
  declaring j() has confused the issue, and the "undefined"
  behaviour _happens_ to be completely irrelevant, as
  people would find out if they actually bothered to try
  the example - even the badly written one i sent in -
  because you still get the buffer over-run even before
  the assignment of j (undefined) to i[b] (which _is_ defined).
 

> | instead, it overwrites memory and corrupts things
> | because... well... here's a patch :)
> 
> Yeah, that is one posssible instance of "undefined behaviour".
> 
> | if you use valarray<some_complicated_class_with_lots_of_memory>
> | then this bug becomes really, really obvious and serious.
> 
> Can you be more specific?  

 yes.

> The example you gave features an undefined
> behaviour. 

 thank you - i am pleased to be asked a useful question, instead
 of fobbed off with stupid comments, and am therefore more than
 happy to answer.

 i clarified in a later post, i'll check your other message
 before replying....

 okay.  let's re-do this example:

 valarray<bool> b(4);

 b[1] = true;
 b[2] = true;

 valarray<int>  i(4);

 i = 9;

 valarray<int> j(i[b]);

 expected behaviour: 

 j[0] = 0
 j[1] = 9
 j[2] = 9
 j[3] = 0

 ACTUAL behaviour:

 buffer over-run beyond end of j, looking in b[5], b[6], b[7].... for
 (j.size() - 2) "true" values, over-writing into j[7,8,9,....]
 etc with i[7,8,9....].


 with the patch i submitted, the expected - and most importantly
 DEFINITELY DEFINED behaviour - occurs.

 witout the patch i submitted, the buffer overrun behaviour
 which is most DEFINITELY NOT CORRECT behaviour - occurs.

 l.