Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: PATCH: Add g:: parameter expansion flag
- X-seq: zsh-workers 29259
- From: Mikael Magnusson <mikachu@xxxxxxxxx>
- To: Peter Stephenson <Peter.Stephenson@xxxxxxx>
- Subject: Re: PATCH: Add g:: parameter expansion flag
- Date: Fri, 13 May 2011 11:51:13 +0200
- Cc: zsh-workers@xxxxxxx
- 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=
- In-reply-to: <20110513095434.24e81474@pwslap01u.europe.root.pri>
- List-help: <mailto:zsh-workers-help@zsh.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:zsh-workers@zsh.org>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <110512070408.ZM29757@torch.brasslantern.com> <1305215346-27247-1-git-send-email-mikachu@gmail.com> <BANLkTimyL3wQq=H-JR+QCB7qnSk0oTCAgw@mail.gmail.com> <20110513095434.24e81474@pwslap01u.europe.root.pri>
On 13 May 2011 10:54, Peter Stephenson <Peter.Stephenson@xxxxxxx> wrote:
> On Thu, 12 May 2011 21:41:36 +0200
> Mikael Magnusson <mikachu@xxxxxxxxx> wrote:
>> On 12 May 2011 17:49, Mikael Magnusson <mikachu@xxxxxxxxx> 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: は
>> 1
>>
>> Not exactly the intended result :).
>>
>> So I am pretty sure I want to use META_HREALLOC, is that correct? Ie
>> if (!copied)
>> val = dupstring(val), copied = 1;
>> val = getkeystring(val, &len, getkeys, NULL);
>> val = 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 :).
--
Mikael Magnusson
Messages sorted by:
Reverse Date,
Date,
Thread,
Author