From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10857 invoked by alias); 13 May 2011 11:54:21 -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: 29260 Received: (qmail 7722 invoked from network); 13 May 2011 11:54: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.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, SPF_HELO_PASS autolearn=ham version=3.3.1 Received-SPF: none (ns1.primenet.com.au: domain at csr.com does not designate permitted sender hosts) Date: Fri, 13 May 2011 12:54:08 +0100 From: Peter Stephenson To: Subject: Re: PATCH: Add g:: parameter expansion flag Message-ID: <20110513125408.314f6359@pwslap01u.europe.root.pri> In-Reply-To: References: <110512070408.ZM29757@torch.brasslantern.com> <1305215346-27247-1-git-send-email-mikachu@gmail.com> <20110513095434.24e81474@pwslap01u.europe.root.pri> Organization: Cambridge Silicon Radio X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.0; i386-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.103.11.49] X-Scanned-By: MailControl A-10-80-00 (www.mailcontrol.com) on 10.71.0.122 On Fri, 13 May 2011 11:51:13 +0200 Mikael Magnusson 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 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