Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@stdcxx.apache.org
Received-SPF: pass (athena.apache.org: domain of msebor@gmail.com designates
 66.249.82.236 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:organization:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:sender;
        b=GLYVCmfxZrW5u8cTz0VRqDBiqzdqUCIFurjyPy39vpF81y9NIZHDRsxp36ueXj7+7DGxtRvzpoJK+KLxZg6Shb5LwpCEuhee7uoxRVR8DpezJQIZE8XNoQPjrQoAaMvD6vEIavCIK3g1vmptPsSD8k2o2PolEH0Z6BUshNrrJR0=
Message-ID: <4845912C.8030305@roguewave.com>
Date: Tue, 03 Jun 2008 12:45:00 -0600
From: Martin Sebor <sebor@roguewave.com>
Organization: Rogue Wave Software, Inc.
User-Agent: Thunderbird 2.0.0.14 (X11/20080501)
MIME-Version: 1.0
To: dev@stdcxx.apache.org
Subject: Re: [jira] Commented: (STDCXX-901) 26.class.gslice test fails
References: <1685660362.1212456165037.JavaMail.jira@brutus>
 <CFFDD219128FD94FB4F92B99F52D0A499AA876@exchmail01.Blue.Roguewave.Com>
In-Reply-To: 
 <CFFDD219128FD94FB4F92B99F52D0A499AA876@exchmail01.Blue.Roguewave.Com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: Martin Sebor <msebor@gmail.com>

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 ("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.

Martin