From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27183 invoked by alias); 15 Nov 2016 20:04:36 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 39950 Received: (qmail 25519 invoked from network); 15 Nov 2016 20:04:36 -0000 X-Qmail-Scanner-Diagnostics: from know-smtprelay-omc-10.server.virginmedia.net by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(80.0.253.74):SA:0(-0.0/5.0):. Processed in 2.624367 secs); 15 Nov 2016 20:04:36 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: p.w.stephenson@ntlworld.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _smtprelay.virginmedia.com designates 80.0.253.74 as permitted sender) X-Originating-IP: [86.21.219.59] X-Spam: 0 X-Authority: v=2.1 cv=Ha/pNXw8 c=1 sm=1 tr=0 a=utowdAHh8RITBM/6U1BPxA==:117 a=utowdAHh8RITBM/6U1BPxA==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=kj9zAlcOel0A:10 a=yeaLGQm7wVmDzS-vAqgA:9 a=CjuIK1q_8ugA:10 Date: Tue, 15 Nov 2016 19:57:21 +0000 From: Peter Stephenson To: "zsh-workers@zsh.org" Subject: Re: [PATCH] Optimization of getarrvalue() Message-ID: <20161115195721.43648236@ntlworld.com> In-Reply-To: References: <1478635899.1897979.781551353.05792438@webmail.messagingengine.com> <20161109114207.6b929440@pwslap01u.europe.root.pri> <161109080328.ZM6075@torch.brasslantern.com> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.28; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Mon, 14 Nov 2016 21:32:19 +0900 "Jun T." wrote: > The original (before a1633e0) behavior is already quite > confusing to me. For example, > > zsh% nargs "${(@)a[i]}" > > will output 0 only for i=0. On the other hand > > zsh% nargs "${(@)a[i,i]}" > > will output 0 for i=0 and 2. 0 is an invalid subscript, which is probably the difference in the first case between it and other values. > If I replace > arrlen_lt(s, v->start) by arrlen_le(s, v->start) > (which may look reasonable since the array s[] is 0-based) > then nargs "${(@)a[i,i]}" will output 0 only for i=0. > But then "make check" fails in two tests (D04parameter and > Y01completion). The parameter test is testing setopt rcexpandparam local -A hash=(X x) print LOST key=$hash[(I)y] val=$hash[(R)Y] outputs LOST with the arguments removed. With your change you get an array wth an empty element and that doesn't happen. I guess the differences are to do with the way the value of the end index is used, with the hash case apparently behaving more like an array slice than an invidivudal index and the latter being the odd one out (but also the most commonly used case). It may be too late to disentangle this. pws