From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28043 invoked from network); 14 Nov 1998 15:43:50 -0000 Received: from math.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 14 Nov 1998 15:43:50 -0000 Received: (from list@localhost) by math.gatech.edu (8.9.1/8.9.1) id KAA10770; Sat, 14 Nov 1998 10:43:17 -0500 (EST) Resent-Date: Sat, 14 Nov 1998 10:43:17 -0500 (EST) Message-Id: <9811141526.AA19988@ibmth.df.unipi.it> To: zsh-workers@math.gatech.edu (Zsh hackers list) Subject: Re: Associative arrays and memory In-Reply-To: ""Bart Schaefer""'s message of "Fri, 13 Nov 1998 09:57:17 NFT." <981113095717.ZM17384@candle.brasslantern.com> Date: Sat, 14 Nov 1998 16:26:40 +0100 From: Peter Stephenson Resent-Message-ID: <"WAleC2.0.De2.LKQJs"@math> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/4633 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu "Bart Schaefer" wrote: > } 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? Yes, it looks like you're right. Maybe it's still unnecessarily confusing. The struct param is really just a placeholder with a type flag for the real information. > zagzig<17> HISTSIZE=1000 > zagzig<18> HISTSIZE=0 echo hello > hello > zagzig<19> echo $HISTSIZE > 2 This seems to be OK after restoring the old behaviour, so I haven't look further into what had gone wrong. > } 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? Rats, I just looked at zle_params.c and you're right --- they're marked special. I had wrongly assumed it was just a case of setting the value at the start and using it at the end, but there tied to functions. That doesn't mean assoc arrays need to be the same, though. The case that needs worrying about is the following: hash=(?...?) builtin_or_func where the ?...? represents whatever we pick for whole array assignments. If there is none, there's no problem; that's the only case where copying parameters is necessary. There's also no problem if the hash is simply used for storing information and is not tied to special variables or functions. You only need a special mechanism for restoration for something like $path, where there's an internal variable that needs setting; simply restoring the struct param won't do that. If we can agree that use of assoc arrays is simply going to be by direct access to the parameter we can avoid ever copying it: the above shell pseudocode simply makes the supplied $hash available for the duration of builtin_func. It would certainly keep things much simpler, and I can provide a patch straight away. So, the question is are there any uses for special hashes which would require tying them directly to an internal variable or function, or can they always be accessed by the standard parameter functions? I would think the whole point of using assoc arrays is to avoid any unpleasantness of the former kind. Probably Sven can answer that better than anyone. -- Peter Stephenson Tel: +39 050 844536 WWW: http://www.ifh.de/~pws/ Dipartimento di Fisica, Via Buonarroti 2, 56100 Pisa, Italy