Crash bug in typeset -T

Crash bug in typeset -T

[Bart Schaefer]

torch% typeset -T FOO foo
torch% typeset -p FOO foo
typeset FOO=''
typeset -a foo
foo=()

So far, so good.  Now:

torch% typeset -T FOO bar
torch% typeset -p FOO foo bar
typeset FOO=''
typeset -a foo
foo=('')
typeset -a bar
bar=()

Curious, look what happened to $foo.  Now:

torch% unset FOO
torch% typeset -p FOO foo bar
typeset: no such variable: FOO
typeset: no such variable: bar
typeset -a foo
foo=()
torch% foo=(x y z)
zsh: segmentation fault (core dumped)  Src/zsh -f

Similar things happen if you unset the array instead of the scalar:

torch% typeset -T FOO foo
torch% typeset -T FOO bar
torch% unset foo
torch% typeset -p FOO foo bar
typeset: no such variable: FOO
typeset: no such variable: foo
typeset -a bar
bar=()
torch% bar=(x y z)
zsh: segmentation fault (core dumped)  Src/zsh -f

This also happens if you unset bar and then assign to foo.  (What I was
looking for when I found this, was a way to untie FOO from foo without
unsetting both of them.)  Related oddness:

torch% typeset -T FOO foo
torch% typeset -T FOO=x:y:z bar
torch% typeset -p FOO foo bar
typeset FOO=x:y:z
typeset -a foo
foo=(x y z)
typeset -a bar
bar=()

Note that foo got the value assigned to FOO, bar did not.  If FOO and foo
were not already tied, bar would have had the value.  Yet:

torch% unset bar
torch% typeset -p FOO foo bar
typeset: no such variable: FOO
typeset: no such variable: bar
typeset -a foo
foo=()

Obviously "typeset -T" needs to check if it's being applied to a parameter
that's already tied ... but what should it do in that case?  Error?  Unset
and then re-tie?  There is precedent for the latter - a change of type of
either variable in the tied pair, unsets the other:

torch% typeset -T FOO=1 foo
torch% typeset -i FOO
torch% typeset -p FOO foo
typeset: no such variable: foo
typeset -i FOO=1

Of course what I was hoping was that "typeset +T" would disentangle the
variables yet leave them independently set, but:

torch% typeset +T FOO
typeset: use unset to remove tied variables

Re: Crash bug in typeset -T

[Peter Stephenson]

On Sun, 27 Feb 2011 22:37:40 -0800
Bart Schaefer <schaefer@brasslantern.com> wrote:
> Obviously "typeset -T" needs to check if it's being applied to a
> parameter that's already tied ... but what should it do in that
> case?  Error?

Within looking in any detail, I think it's going to have to be an error.
The reason you need to unset variables to retie them is that undoing it
is a lot of tricky code all over the place creating messy special cases.
The real fix is the same real fix as to most typeset problems: the code
should delegate much more to functions for different types of variables
reached via a uniform interface.

-- 
Peter Stephenson <pws@csr.com>            Software Engineer
Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom

Re: Crash bug in typeset -T

[Bart Schaefer]

On Feb 28,  9:49am, Peter Stephenson wrote:
} Subject: Re: Crash bug in typeset -T
}
} On Sun, 27 Feb 2011 22:37:40 -0800
} Bart Schaefer <schaefer@brasslantern.com> wrote:
} > Obviously "typeset -T" needs to check if it's being applied to a
} > parameter that's already tied ... but what should it do in that
} > case?  Error?
} 
} Within looking in any detail, I think it's going to have to be an error.

OK, patch below does this, and improves a couple of other error messages.

Turns out that it's only necessary to check the scalar; if the array
is being re-tied, re-creating it unsets the original scalar.  This is
fortunate because the code never retrieves the paramtab node for the
array.

} The reason you need to unset variables to retie them is that undoing it
} is a lot of tricky code all over the place creating messy special cases.

Seems as though bin_typeset() could save the values, unset the scalar
(which has the side-effect of unsetting the array), and then recreate
both parameters.  However, I haven't attempted to do that.

--- Src/builtin.c.~1.247.~	2011-02-27 10:21:53.000000000 -0800
+++ Src/builtin.c	2011-02-28 19:55:09.000000000 -0800
@@ -2420,12 +2420,12 @@
 	}
 	if (!strcmp(asg0.name, asg->name)) {
 	    unqueue_signals();
-	    zerrnam(name, "can't tie a variable to itself");
+	    zerrnam(name, "can't tie a variable to itself: %s", asg0.name);
 	    return 1;
 	}
 	if (strchr(asg0.name, '[') || strchr(asg->name, '[')) {
 	    unqueue_signals();
-	    zerrnam(name, "can't tie array elements");
+	    zerrnam(name, "can't tie array elements: %s", asg0.name);
 	    return 1;
 	}
 	/*
@@ -2440,6 +2440,11 @@
 	if ((pm = (Param) paramtab->getnode(paramtab, asg0.name))
 	    && !(pm->node.flags & PM_UNSET)
 	    && (locallevel == pm->level || !(on & PM_LOCAL))) {
+	    if (pm->node.flags & PM_TIED) {
+		unqueue_signals();
+		zerrnam(name, "can't tie already tied scalar: %s", asg0.name);
+		return 1;
+	    }
 	    if (!asg0.value && !(PM_TYPE(pm->node.flags) & (PM_ARRAY|PM_HASHED)))
 		oldval = ztrdup(getsparam(asg0.name));
 	    on |= (pm->node.flags & PM_EXPORTED);