zsh-workers
 help / color / mirror / code / Atom feed
From: Peter Stephenson <Peter.Stephenson@csr.com>
To: <zsh-workers@zsh.org>
Subject: Re: PATCH: Add g:: parameter expansion flag
Date: Fri, 13 May 2011 12:54:08 +0100	[thread overview]
Message-ID: <20110513125408.314f6359@pwslap01u.europe.root.pri> (raw)
In-Reply-To: <BANLkTikyO3hb6=-ovbY2bkW5HGOszOVPWg@mail.gmail.com>

On Fri, 13 May 2011 11:51:13 +0200
Mikael Magnusson <mikachu@gmail.com> wrote:
> >> So I am pretty sure I want to use META_HREALLOC, is that correct?
> > 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).

USEHEAP is fine if you don't mind further modifications to the string
propagating back to the original.  In some places the string might not
be modifiable, or might refer to a permanently stored string, so you
wouldn't want to do that.  That may not be the case here; it needs
deciding case by case.

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

The real problem is the combination of a long string that's continually
being extended, typically before any other heap allocation has been
done; that's the case hrealloc() is best at handling.

-- 
Peter Stephenson <pws@csr.com>            Software Engineer
Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom


  reply	other threads:[~2011-05-13 11:54 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
2011-05-13 11:54                           ` Peter Stephenson [this message]
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=20110513125408.314f6359@pwslap01u.europe.root.pri \
    --to=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).