Re: parameter structs still alive

Re: parameter structs still alive

[Sven Wischnowsky]

Peter Stephenson wrote:

> ...
>
> 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.)

Seems to work fine except for two function in the parameter module
which made named dirs and aliases be removed if one dared to unload
that module.

> Does anybody know what the second argument to the unsetfn() family is for?

It's set if the unset function was invoked by the user calling `unset' 
instead of an endparamscope() (I think the `exp' is for `explicit').

This is useful, for example, the completion code uses it to set its
special parameters to the empty string/array only if the user unset
them explicitly. If called from endparamscope(), the values are not
changed so that the completion code can still use them after the
widget has finished.

Bye
 Sven

diff -ru ../z.old/Src/Modules/parameter.c Src/Modules/parameter.c
--- ../z.old/Src/Modules/parameter.c	Tue Jan 25 09:15:13 2000
+++ Src/Modules/parameter.c	Tue Jan 25 10:23:40 2000
@@ -1418,6 +1418,9 @@
     int i;
     HashNode hn, next, hd;
 
+    if (!ht)
+	return;
+
     for (i = 0; i < nameddirtab->hsize; i++)
 	for (hn = nameddirtab->nodes[i]; hn; hn = next) {
 	    next = hn->next;
@@ -1426,9 +1429,6 @@
 		nameddirtab->freenode(hd);
 	}
 
-    if (!ht)
-	return;
-
     for (i = 0; i < ht->hsize; i++)
 	for (hn = ht->nodes[i]; hn; hn = hn->next) {
 	    struct value v;
@@ -1649,6 +1649,9 @@
     int i;
     HashNode hn, next, hd;
 
+    if (!ht)
+	return;
+
     for (i = 0; i < aliastab->hsize; i++)
 	for (hn = aliastab->nodes[i]; hn; hn = next) {
 	    next = hn->next;
@@ -1657,9 +1660,6 @@
 		(hd = aliastab->removenode(aliastab, hn->nam)))
 		aliastab->freenode(hd);
 	}
-
-    if (!ht)
-	return;
 
     for (i = 0; i < ht->hsize; i++)
 	for (hn = ht->nodes[i]; hn; hn = hn->next) {

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: parameter structs still alive

[Peter Stephenson]

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 <pws@pwstephenson.fsnet.co.uk>

parameter structs still alive

[Sven Wischnowsky]

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...

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de