From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 767 invoked from network); 13 Nov 1998 18:05:11 -0000 Received: from math.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 13 Nov 1998 18:05:11 -0000 Received: (from list@localhost) by math.gatech.edu (8.9.1/8.9.1) id MAA16419; Fri, 13 Nov 1998 12:59:22 -0500 (EST) Resent-Date: Fri, 13 Nov 1998 12:59:22 -0500 (EST) From: "Bart Schaefer" Message-Id: <981113095717.ZM17384@candle.brasslantern.com> Date: Fri, 13 Nov 1998 09:57:17 -0800 In-Reply-To: <9811131616.AA30250@ibmth.df.unipi.it> Comments: In reply to Peter Stephenson "Associative arrays and memory" (Nov 13, 5:16pm) References: <9811131616.AA30250@ibmth.df.unipi.it> X-Mailer: Z-Mail (4.0b.820 20aug96) To: Peter Stephenson , zsh-workers@math.gatech.edu (Zsh hackers list) Subject: Re: Associative arrays and memory MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Resent-Message-ID: <"pQkIB3.0.U04.wD7Js"@math> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/4625 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu On Nov 13, 5:16pm, Peter Stephenson wrote: } Subject: Associative arrays and memory } } It does seem the existing ztrdup()'s in what's now copyparam() are } memory leaks. This will need fixing in any case, independently from } assoc arrays. I'm not so sure any more. When restore_params() is called, it uses the pm->sets functions to assign directly to the struct param already in the paramtab. So that memory is now owned by the paramtab and should be freed when the param next becomes unset ... right? } However, it looks like the only purpose of copyparam() is simply to } save special parameters and only in the following case: } foo=bar some-builtin } to restore $foo (it's separate from the usual local restore mechanism). I appear to have broken it somehow, then: zagzig<17> HISTSIZE=1000 zagzig<18> HISTSIZE=0 echo hello hello zagzig<19> echo $HISTSIZE 2 Nonspecial variables work: zagzig<23> FOO=before zagzig<24> FOO=after echo hello hello zagzig<25> echo $FOO before } There are currently no special assoc arrays, of course, and it should } probably be possible to prevent there being any What about the discussion that started all this -- using an associative array to give user access to shell-internal completion data? } So I'd recommend removing all references to assoc } arrays from copyparam(), i.e. putting that part of the code back how } it was, maybe with a } DPUTS(PM_TYPE(pm->flags) == PM_HASHED, "attempt to copy assoc array") } to be on the safe side. } } Combining that with my other suggestion of separating assoc array } returns out of getaparam() would be a big help in warding off possible } memory leaks. (Unless `shift hash', which is where getaparam() comes } in, is really supposed to work? It does something at the moment, but } what does it mean --- randomly remove element from hash?? Same goes } for the call in `set -A': there's no point getting an array only to } find you can't set it because it's the wrong type.) If you have time and inclination, please go ahead and do this. I'm not going to be able to work on it again until tomorrow at the earliest. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com