From: Mikael Magnusson <mikachu@gmail.com>
To: Peter Stephenson <Peter.Stephenson@csr.com>
Cc: zsh-workers@zsh.org
Subject: Re: PATCH: Add g:: parameter expansion flag
Date: Fri, 13 May 2011 11:51:13 +0200 [thread overview]
Message-ID: <BANLkTikyO3hb6=-ovbY2bkW5HGOszOVPWg@mail.gmail.com> (raw)
In-Reply-To: <20110513095434.24e81474@pwslap01u.europe.root.pri>
On 13 May 2011 10:54, Peter Stephenson <Peter.Stephenson@csr.com> wrote:
> On Thu, 12 May 2011 21:41:36 +0200
> Mikael Magnusson <mikachu@gmail.com> wrote:
>> On 12 May 2011 17:49, Mikael Magnusson <mikachu@gmail.com> 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
next prev parent reply other threads:[~2011-05-13 9:51 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-11 13:02 PATCH: expanding parameters like echo/print builtins Mikael Magnusson
2011-05-11 15:03 ` Bart Schaefer
2011-05-11 15:14 ` Mikael Magnusson
2011-05-11 16:03 ` Bart Schaefer
2011-05-11 16:22 ` Mikael Magnusson
2011-05-11 16:48 ` Bart Schaefer
2011-05-11 17:11 ` Mikael Magnusson
2011-05-11 15:47 ` Oliver Kiddle
2011-05-11 16:21 ` Peter Stephenson
2011-05-11 16:38 ` Mikael Magnusson
2011-05-11 17:07 ` Peter Stephenson
2011-05-11 17:19 ` Mikael Magnusson
2011-05-11 17:26 ` Peter Stephenson
2011-05-11 17:35 ` Mikael Magnusson
2011-05-11 17:43 ` Mikael Magnusson
2011-05-12 10:10 ` Bart Schaefer
2011-05-12 10:40 ` Mikael Magnusson
2011-05-12 14:04 ` Bart Schaefer
2011-05-12 15:49 ` PATCH: Add g:: parameter expansion flag Mikael Magnusson
2011-05-12 19:41 ` Mikael Magnusson
2011-05-13 8:54 ` Peter Stephenson
2011-05-13 9:51 ` Mikael Magnusson [this message]
2011-05-13 11:54 ` Peter Stephenson
2011-05-13 12:38 ` Mikael Magnusson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='BANLkTikyO3hb6=-ovbY2bkW5HGOszOVPWg@mail.gmail.com' \
--to=mikachu@gmail.com \
--cc=Peter.Stephenson@csr.com \
--cc=zsh-workers@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).