zsh-workers
 help / color / mirror / code / Atom feed
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


  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).