From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25611 invoked by alias); 16 Nov 2016 14:43:28 -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: 39955 Received: (qmail 12537 invoked from network); 16 Nov 2016 14:43:28 -0000 X-Qmail-Scanner-Diagnostics: from rcpt-mqugw.biglobe.ne.jp 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(133.208.100.3):SA:0(-2.9/5.0):. Processed in 2.210592 secs); 16 Nov 2016 14:43:28 -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=-2.9 required=5.0 tests=RCVD_IN_DNSWL_NONE, RP_MATCHES_RCVD,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: takimoto-j@kba.biglobe.ne.jp X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at spf01.biglobe.ne.jp designates 133.208.100.3 as permitted sender) X-Biglobe-Sender: Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: [PATCH] Optimization of getarrvalue() From: "Jun T." In-Reply-To: <20161115195721.43648236@ntlworld.com> Date: Wed, 16 Nov 2016 23:06:13 +0900 Content-Transfer-Encoding: 7bit Message-Id: <77EB3614-F9E2-4BEB-B93C-99DFD34A504F@kba.biglobe.ne.jp> References: <1478635899.1897979.781551353.05792438@webmail.messagingengine.com> <20161109114207.6b929440@pwslap01u.europe.root.pri> <161109080328.ZM6075@torch.brasslantern.com> <20161115195721.43648236@ntlworld.com> To: "zsh-workers@zsh.org" X-Mailer: Apple Mail (2.1510) X-Biglobe-Spnum: 61117 On 2016/11/16, at 4:57, Peter Stephenson wrote: > On Mon, 14 Nov 2016 21:32:19 +0900 > "Jun T." wrote: >> >> 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. The document says (15.2.1) If the KSH_ARRAYS option is not set, then by default accesses to an array element with a subscript that evaluates to zero return an empty string, so someone may expect that "${(@)a[0]}" is also replaced by an empty string "" rather than removed from the command line. But I'm not sure. And I fear changing this behavior might break some existing scripts. > 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 haven't yet understood how associative arrays are handled in C code, but how about the following patch? With this patch all the test passes, and "${(@)a[i,i]}" becomes an empty array (and removed from the command line) only if i=0. I think no (reasonable) scripts are relying on the current behavior that "${(@)a[i,i]}" is removed if i==($#a+1). diff --git a/Src/params.c b/Src/params.c index 3c8658c..c501e5d 100644 --- a/Src/params.c +++ b/Src/params.c @@ -2291,11 +2291,12 @@ getarrvalue(Value v) if (v->end < 0) v->end += arrlen(s) + 1; - /* Null if 1) array too short, 2) index still negative */ - if (v->end <= v->start) { + if (!*s || v->end <= v->start) { + /* Empty array if 1) s[] is empty or 2) inconsistent indexes */ s = arrdup_max(nular, 0); } - else if (arrlen_lt(s, v->start) || v->start < 0) { + else if (arrlen_le(s, v->start) || v->start < 0) { + /* Null if 1) array too short, 2) index still negative */ s = arrdup_max(nular, 1); } else { /* Copy to a point before the end of the source array: