PATCH: tied parameters bug

PATCH: tied parameters bug

[Oliver Kiddle]

I noticed this bug while looking at aspects of the parameter code:

% g() {
>   local SC="hello"
>   unset sc
> }
% typeset -T SC sc
% g

Tied parameters use pm->ename to store the name of the parameter they
are tied to in string form. So in this code, it unsets the local
instead of the global SC. As a result, the global SC still exists and
if used, fairly shortly results in a seg fault. The same problem
applies the other way around (unsetting the scalar with a local array).

The fix below relies on the tied parameters being at the same local
level (which I believe always holds true). It makes the code search for
the parameter at the correct local level and then unsets it which
requires a nasty hack to avoid the parameter node being removed from
the table.

Oliver

Index: Src/params.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/params.c,v
retrieving revision 1.65
diff -u -r1.65 params.c
--- Src/params.c	5 Aug 2002 12:36:00 -0000	1.65
+++ Src/params.c	8 Oct 2002 09:26:44 -0000
@@ -2234,8 +2234,21 @@
     /* remove it under its alternate name if necessary */
     if (pm->ename && !altflag) {
 	altpm = (Param) paramtab->getnode(paramtab, pm->ename);
-	if (altpm)
+	/* tied parameters are at the same local level as each other */
+	oldpm = NULL;
+	while (altpm && altpm->level > pm->level) {
+	    /* param under alternate name hidden by a local */
+	    oldpm = altpm;
+	    altpm = altpm->old;
+	}
+	if (altpm) {
+	    if (oldpm) {
+		oldpm->old = altpm->old;
+		/* fudge things so removenode isn't called */
+		altpm->level = locallevel;
+	    }
 	    unsetparam_pm(altpm, 1, exp);
+	}
     }
 
     /*

This e-mail and any attachment is for authorised use by the intended recipient(s) only.  It may contain proprietary material, confidential information and/or be subject to legal privilege.  It should not be copied, disclosed to, retained or used by, any other party.  If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender.  Thank you.

Re: PATCH: tied parameters bug

[Oliver Kiddle]

Another bug with tied parameters:
  typeset -A hash
  typeset -T 'hash[one]' h
  h=(whatever)

Same applies for ordinary arrays. The patch checks both parameters
because `typeset: h[1]: can't create local array elements' is not an
ideal error message, especially when it isn't trying to create a local.

Is the ename field of the param struct really used for anything other
than tied parameters? If not, the comment next to it in zsh.h is
confusing.

Yesterday, I wrote:
> Tied parameters use pm->ename to store the name of the parameter they
> are tied to in string form. So in this code, it unsets the local
> instead of the global SC. As a result, the global SC still exists and

This still didn't work entirely properly if the tied variable is both
local and hidden by another local. I hope I've now got it right. I'm
considering a very different (more nameref like) way of doing tied
parameters in my new parameter code. 

Oliver

Index: Src/builtin.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/builtin.c,v
retrieving revision 1.86
diff -u -r1.86 builtin.c
--- Src/builtin.c	19 Sep 2002 17:57:57 -0000	1.86
+++ Src/builtin.c	9 Oct 2002 08:41:11 -0000
@@ -2116,6 +2116,11 @@
 	    zerrnam(name, "can't tie a variable to itself", NULL, 0);
 	    return 1;
 	}
+	if (strchr(asg0.name, '[') || strchr(asg->name, '[')) {
+	    unqueue_signals();
+	    zerrnam(name, "can't tie array elements", NULL, 0);
+	    return 1;
+	}
 	/*
 	 * Keep the old value of the scalar.  We need to do this
 	 * here as if it is already tied to the same array it
Index: Src/params.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/params.c,v
retrieving revision 1.65
diff -u -r1.65 params.c
--- Src/params.c	5 Aug 2002 12:36:00 -0000	1.65
+++ Src/params.c	9 Oct 2002 08:41:11 -0000
@@ -2234,8 +2234,21 @@
     /* remove it under its alternate name if necessary */
     if (pm->ename && !altflag) {
 	altpm = (Param) paramtab->getnode(paramtab, pm->ename);
-	if (altpm)
+	/* tied parameters are at the same local level as each other */
+	oldpm = NULL;
+	while (altpm && altpm->level > pm->level) {
+	    /* param under alternate name hidden by a local */
+	    oldpm = altpm;
+	    altpm = altpm->old;
+	}
+	if (altpm) {
+	    if (oldpm && !altpm->level) {
+		oldpm->old = NULL;
+		/* fudge things so removenode isn't called */
+		altpm->level = 1;
+	    }
 	    unsetparam_pm(altpm, 1, exp);
+	}
     }
 
     /*

This e-mail and any attachment is for authorised use by the intended recipient(s) only.  It may contain proprietary material, confidential information and/or be subject to legal privilege.  It should not be copied, disclosed to, retained or used by, any other party.  If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender.  Thank you.

Re: PATCH: tied parameters bug

[Peter Stephenson]

Oliver Kiddle wrote:
> Is the ename field of the param struct really used for anything other
> than tied parameters? If not, the comment next to it in zsh.h is
> confusing.

It may be historical; possibly at one stage it only pointed one way,
from a path-array to a PATH-array, but now it points both ways in both
types of tied parameters, internal and user-defined.  I don't think it's
used for anything else.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 692070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************