stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Travis Vitek" <Travis.Vi...@roguewave.com>
Subject RE: [jira] Commented: (STDCXX-901) 26.class.gslice test fails
Date Wed, 04 Jun 2008 01:13:46 GMT
 

Martin Sebor wrote:
>
>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...
>>>
>> 
>> [...]
>>
>> int main ()
>> {
>>       //               + length
>>       //               |    +- stride
>>       //               |    |
>>       //               v    v
>>       test ("1@10", 0, "",  "");
>>       test ("1@10", 0, "0", "0");
>>       test ("1@10", 0, "1", "1");
>>       test ("1@10", 0, "1", "2");
>>       test ("1@10", 0, "1", "3");
>> 
>>       test ("1@10", 0, "2", "1");
>>       test ("1@10", 0, "2", "2");
>>       test ("1@10", 0, "3", "3");
>>       test ("1@10", 0, "2", "3");
>> 
>>       test ("1@10", 0, "5", "1");
>>       test ("1@10", 1, "5", "1");
>>       test ("1@10", 1, "5,2", "1,2");
>> 
>>       test ("1@10", 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.

In that case, then I think your new gslice code [shown earlier in this
thread] has issues with the same case. The following snip will calculate
the wrong value for the number of indexes if an element of the length
array is zero. This is the problematic code...

    for (size_t i = 0; i != length; ++i) {
        nelems *= _C_length [i];
    }

I believe the easy fix would be...

    for (size_t i = 0; i != length; ++i) {
        if (_C_length [i])
            nelems *= _C_length [i];
    }

Then, of course you would need to fix the loop that calculates the
values in the _C_inxs array to handle the special case

    while (inx && cache [inx - 1] == _C_length [inx - 1] - 1)
        --inx;

The following should work.

    for (/**/; inx; --inx)
    {
        if (   _C_length [__n - 1]
            && cache [__n - 1] != _C_length [__n - 1] - 1)
            break;
    }

Travis
>
>Martin
>

Mime
View raw message