From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2381 invoked by alias); 13 May 2011 09:51:30 -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: 29259 Received: (qmail 3667 invoked from network); 13 May 2011 09:51:19 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 Received-SPF: pass (ns1.primenet.com.au: SPF record at _spf.google.com designates 209.85.212.43 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=kgnozeD37YeV08GHda1iFAKasvwbkzX4qjZEEWWvETc=; b=oLkZ1YnJwkkdfo/eMIbqy9afryVVQSnN02w8lLW8yhiiF8eQjrbwgJLjQ0+lqjVvMb EOhVRe5ObRJpKUDNTy9z3106SZ6c2Ch3FE0xPoGepO0dVCSgAM4C6yhd+8uTCv0J3ukj Bpe4MZc6p7PCpMqXTK7Fm+xqnAY4QPZEM5v7k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=u9A0j3MHo7u2veBqFoPTPn/i+ULwkxQG7K5PNOADTm1lUNvG6KvqVCNCru82QFNDpR MZi3OEhozo2XhLG2T4TVJ8Jg0tb6p5es9it63TY6pYTvx78P6Yj8auWo8FlUUOU7SNRe f8mlovau1O6/gz0egrgkbyCensQeVAWpvuVoE= MIME-Version: 1.0 In-Reply-To: <20110513095434.24e81474@pwslap01u.europe.root.pri> References: <110512070408.ZM29757@torch.brasslantern.com> <1305215346-27247-1-git-send-email-mikachu@gmail.com> <20110513095434.24e81474@pwslap01u.europe.root.pri> Date: Fri, 13 May 2011 11:51:13 +0200 Message-ID: Subject: Re: PATCH: Add g:: parameter expansion flag From: Mikael Magnusson To: Peter Stephenson Cc: zsh-workers@zsh.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 13 May 2011 10:54, Peter Stephenson wrote: > On Thu, 12 May 2011 21:41:36 +0200 > Mikael Magnusson wrote: >> On 12 May 2011 17:49, Mikael Magnusson wrote: >> > Okay, how's this? I swapped the order so g happens first, and >> > changed the docs as discussed. >> >> Just as I was thinking about committing it, I found a bug. I have to >> metafy the result of getkeystring(). >> % print -Rn ${(g:o:):-'\201\227\343\201\257'}|wc -c >> zsh: command not found: =E3=81=AF >> 1 >> >> Not exactly the intended result :). >> >> So I am pretty sure I want to use META_HREALLOC, is that correct? Ie >> if (!copied) >> val =3D dupstring(val), copied =3D 1; >> val =3D getkeystring(val, &len, getkeys, NULL); >> val =3D metafy(val, len, META_HREALLOC); >> (and same for the isarr case) >> > > That would do, as it's what untok_and_escape() does, although > META_HEAPDUP would probably be OK at this point. Reallocating what's > on the heap is a slightly strange thing to do, since the point of the > heap is to provide quick storage without the need to micromanage it; In that case, isn't USEHEAP better? It'll allocate on the heap if there's anything to escape and otherwise do it in-place. Which is what I thought HREALLOC would do, but I guess that one would do more stuff to try and just grow. Won't it always succeed though, since the to-be reallocated value was just allocated on the line before? (At least when the heap isn't full). > it > tends to be done when there's a long string on the heap that it would > be inefficient to keep duplicating, which isn't the case here. If the > original heap chunk is surrounded by other allocations it has to > duplicate anyway, since the heap doesn't let you reuse memory (until > the whole heap is popped); you can't tell just be looking at the call > whether this will be the case. Why can't the string be long? Not that I think anyone would really notice anyway :). --=20 Mikael Magnusson