From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19554 invoked from network); 24 Jan 2000 19:58:41 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 24 Jan 2000 19:58:41 -0000 Received: (qmail 1511 invoked by alias); 24 Jan 2000 19:58:36 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 9421 Received: (qmail 1503 invoked from network); 24 Jan 2000 19:58:36 -0000 To: zsh-workers@sunsite.auc.dk Subject: Re: parameter structs still alive In-reply-to: "Sven Wischnowsky"'s message of "Mon, 24 Jan 2000 14:53:42 +0100." <200001241353.OAA12217@beta.informatik.hu-berlin.de> Date: Mon, 24 Jan 2000 20:01:02 +0000 From: Peter Stephenson Message-Id: Sven Wischnowsky wrote: > > Having had a look at the output of mem again, I noticed that every > completion adds several blocks of 96 bytes (on a 64 Bit > machine). These are struct pm's for the special parameters that don't > get freed. > > When I wrote the new completion stuff I copied the parameter stuff > from zle_params.c and never really understood why the zleunsetfn() was > written the way it was written. The `if(ext) ...' test together with > the fact that the parameters have the PM_SPECIAL flag have the effect > that the struct are not freed. > > Peter: which is the right way to do such things? Removing the > PM_SPECIAL flag in zleunsetfn() and compunsetfn() at least makes the > structs be freed, but that can't be the right solution... This code was originally written by Zefram, and then modified by me to add the PM_REMOVABLE flag: the problem was the original specials shouldn't even be removed from the table, never mind deleted, if they're going to stay special when unset, which is the advertised behaviour. So we still need some way of distinguishing removable parameters. However, looking at it again, such parameters are all (as far as I can see) created by createparam(), and so can be freed, therefore I should have made unsetparam_pm() free the struct when the flag was present --- i.e. just change the test and comment right at the end of the function. This seems to be working so far, but maybe you should cast an eye over the effect in various modules, too. (We don't need to test for non-removable specials since they were handled a couple of paragraphs back.) Does anybody know what the second argument to the unsetfn() family is for? Index: Src/params.c =================================================================== RCS file: /home/pws/CVSROOT/projects/zsh/Src/params.c,v retrieving revision 1.4 diff -u -r1.4 params.c --- Src/params.c 2000/01/07 19:42:02 1.4 +++ Src/params.c 2000/01/24 19:54:18 @@ -1933,9 +1933,7 @@ adduserdir(oldpm->nam, oldpm->u.str, 0, 0); } - /* Even removable specials shouldn't be deleted. */ - if (!(pm->flags & PM_SPECIAL)) - paramtab->freenode((HashNode) pm); /* free parameter node */ + paramtab->freenode((HashNode) pm); /* free parameter node */ } /* Standard function to unset a parameter. This is mostly delegated to * -- Peter Stephenson