From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 904 invoked from network); 5 Mar 2006 20:42:27 -0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 5 Mar 2006 20:42:27 -0000 Received: (qmail 65339 invoked from network); 5 Mar 2006 20:42:20 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 5 Mar 2006 20:42:20 -0000 Received: (qmail 4613 invoked by alias); 5 Mar 2006 20:42:18 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 22325 Received: (qmail 4602 invoked from network); 5 Mar 2006 20:42:17 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 5 Mar 2006 20:42:17 -0000 Received: (qmail 65049 invoked from network); 5 Mar 2006 20:42:17 -0000 Received: from vms048pub.verizon.net (206.46.252.48) by a.mx.sunsite.dk with SMTP; 5 Mar 2006 20:42:14 -0000 Received: from torch.brasslantern.com ([71.116.81.225]) by vms048.mailsrvcs.net (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPA id <0IVO00G529IDA6M0@vms048.mailsrvcs.net> for zsh-workers@sunsite.dk; Sun, 05 Mar 2006 14:42:14 -0600 (CST) Received: from torch.brasslantern.com (localhost.localdomain [127.0.0.1]) by torch.brasslantern.com (8.13.1/8.13.1) with ESMTP id k25KhGnr025212 for ; Sun, 05 Mar 2006 12:43:25 -0800 Received: (from schaefer@localhost) by torch.brasslantern.com (8.13.1/8.13.1/Submit) id k25KhGoc025211 for zsh-workers@sunsite.dk; Sun, 05 Mar 2006 12:43:16 -0800 Date: Sun, 05 Mar 2006 12:43:16 -0800 From: Bart Schaefer Subject: Re: [PATCH][RFC] check for heap memory in zfree() In-reply-to: <200603051723.k25HNdZI003407@pwslaptop.csr.com> To: "Zsh-workers" Message-id: <060305124316.ZM25210@torch.brasslantern.com> MIME-version: 1.0 X-Mailer: OpenZMail Classic (0.9.2 24April2005) Content-type: text/plain; charset=us-ascii References: <200603051723.k25HNdZI003407@pwslaptop.csr.com> Comments: In reply to Peter Stephenson "Re: [PATCH][RFC] check for heap memory in zfree()" (Mar 5, 5:23pm) On Mar 5, 5:23pm, Peter Stephenson wrote: } Subject: Re: [PATCH][RFC] check for heap memory in zfree() } } Bart Schaefer wrote: } > Maybe someone can remind me why it's up to the parameter set-function } > to free its argument? That seems completely inside-out to me. } } For normal parameters this is typically more efficient (I presume; I } haven't followed it through to make sure) since there's no additional } copy; it's just assigned to the array variable and the old value } is freed. Knowing a bit about how PF thinks, that's probably the right answer. Any objections to my committing my patch? With one additional tweak to call zheapptr() before zarrdup() in the builtin.c hunk. } Later: } > } OR you guys are now going to say: "Don't you know you're not } > } supposed to use typeset with dirstack!!" } > } > You aren't, but the shell isn't supposed to crash, either. } } Why not? schaefer[514] typeset -T DIRSTACK dirstack typeset: dirstack: can't change type of a special parameter IMO a unique array is a distinct type from an ordinary array. } If you weren't supposed to do that kind of thing, dirstack wouldn't } be writeable. Since it is, this needs to be handled transparently. } If it quacks like a parameter and waddles like a parameter, a user } should assume it swims on water like a parameter (er, as it were). Some of our quacking and waddling parameters are already dog-paddling. For example, although you can (without getting warnings) set the -LRZ options on any array, they don't have any effect except to make the array show up in "typeset -LRZ" output. } It seems to me that behind both of these is the tension between the } ability to make a feature look like a parameter and efficiency of } implementation for normal parameters. I think you're only half right. Efficiency isn't the problem when it comes to having an internal construct like the dirstack linked list made visible via an array parameter -- the problem is that there's no way for the other code that manipulates the structure to know that the parameter exists and has its own value rules. The way to fix that is to require that the parameter's rules conform to the internal structure it represents, not the other way around.