>Travis Vitek updated STDCXX-955:
>--------------------------------
>
> Attachment: stdcxx-955.patch
>
>{noformat}
>2008-06-03 Travis Vitek <[EMAIL PROTECTED]>
>
> STDCXX-955
> * include/valarray (gslice::ind_numb): Correctly calculate
> index count when the length array contains a zero.
> * src/valarray.cpp (next_ind): Correctly calculate next index
> when the length array contains a zero.
> * tests/numerics/26.class.gslice.cpp (make_array): Update to
> handle empty strings or other poorly formatted input.
> (get_array_size): Correctly calculate index count when the
> slice has a size array that contains a zero.
> (next_index): Correctly calculate next index when the length
> array contains a zero.
> (test_gslice): Remove unnecessary linefeed from assertion.
> (run_test): Update degenerate testcase to match comment.
>{noformat}
>
So I have one tiny issue with this fix that I should bring up before I
submit it.
The function gslice::ind_numb() is inline and gslice::next_ind() is not.
The functions that use ind_numb() are listed below.
valarray<T>::operator[](const gslice&) const
valarray<T>::valarray(const gslice_array<T>&)
valarray<T>::operator=(const gslice_array<T>&)
The issue is that these functions use ind_numb() to decide how big an
array to allocate, and then they use next_ind() to iterate over those
elements assigning values to each of them. So if ind_numb() returns 4,
but the iteration terminates after just 2 passes, then there would be 2
elements in the array that are probably not supposed to be there.
If the user builds with 4.2.2 headers and links a 4.2.1 library, they
will get the same behavior as they did with 4.2.1. Namely their
application will hang or crash [under conditions from stdcxx-995]
because the gslice iteration code would not contain the fix.
If an application built with 4.2.1 linked the 4.2.2 library it would
also crash, most likely because the allocated array would have 0
elements but the gslice iteration would try to allow multiple elements
to be written. The same app would already crash or hang when linking the
4.2.1 library.
So I'm pretty sure that this change is suitable for 4.2.2 as I can't
envision a scenerio where it would cause any new problems for the user.
Can anyone else? If not I'll submit this change to 4.2.x tomorrow
morning.
Travis
