Travis Vitek wrote:
Martin Sebor commented on STDCXX-901:
-------------------------------------
This is from the binary incompatible rewrite of {{valarray}}
that I've been mentioning for eons (I should finally commit it
on trunk). If it fixes this bug it might spark an idea for a
compatible fix...
Martin,
I'm struggling with what appears to a discrepancy between the standard
and the two implementations I'm testing with.
You mean a bug? ;-)
According to
lib.gslice.cons, a default constructed slice specifies no elements.
Section lib.class.gslice describes gslices that do have lengths and
strides. The example it gives is shown here
[...]
Assume for a moment that we have the following gslice...
start = 0
length = { 0 }
stride = { 0 }
So the indices specified by this slice should be
k = 0 + () * 0
Or just k = 0 because the sum is zero.
i0, i1, k
(0, (), 0) // = 0 + () * 0
So this slice should be a view of 0th element in a given array.
That's my reading too.
I wrote a quick testcase to make sure that I was understanding this
gslice stuff correctly. It creates a valarray and a slice from strings,
then assigns 0 to the resulting gslice_array. This zeros out all
elements specified by the slice. Here is the set of testcases...
int main ()
{
// + length
// | +- stride
// | |
// v v
test ("[EMAIL PROTECTED]", 0, "", "");
test ("[EMAIL PROTECTED]", 0, "0", "0");
test ("[EMAIL PROTECTED]", 0, "1", "1");
test ("[EMAIL PROTECTED]", 0, "1", "2");
test ("[EMAIL PROTECTED]", 0, "1", "3");
test ("[EMAIL PROTECTED]", 0, "2", "1");
test ("[EMAIL PROTECTED]", 0, "2", "2");
test ("[EMAIL PROTECTED]", 0, "3", "3");
test ("[EMAIL PROTECTED]", 0, "2", "3");
test ("[EMAIL PROTECTED]", 0, "5", "1");
test ("[EMAIL PROTECTED]", 1, "5", "1");
test ("[EMAIL PROTECTED]", 1, "5,2", "1,2");
test ("[EMAIL PROTECTED]", 0, "0,0,0", "1,2,3");
return 0;
}
[...]
The STLPort and RW implementations both get stuck in an infinite loop on
the second testcase, so I'm pretty sure that they're broken. I can't
find anything in the standard that says this would be unspecified or
undefined behavior and I don't see anything that calls this out as a
special case. This leads me to believe that this is a bug in both
implementations and I should take it into consideration when applying
any fix.
I agree. There's more than one way to refer to the same slice.
Unless it's computationally expensive to avoid, none of them
should enter an infinite loop or any other kind of undefined
behavior.
Martin
