Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: Bug Report: Variable becomes unset without reason
- X-seq: zsh-workers 44664
- From: Peter Stephenson <p.stephenson@xxxxxxxxxxx>
- To: <zsh-workers@xxxxxxx>
- Subject: Re: Bug Report: Variable becomes unset without reason
- Date: Wed, 14 Aug 2019 15:04:33 +0100
- Cms-type: 201P
- Dkim-filter: OpenDKIM Filter v2.11.0 mailout1.w1.samsung.com 20190814140436euoutp01065393f3b8623d551384c12446519f49~6zw04nxIf1138111381euoutp01i
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1565791476; bh=b9uAfATFoASHooJrb49QHRilfH9Z/wPIyGI9BON3198=; h=Subject:From:To:Date:In-Reply-To:References:From; b=E3JPm8HP4frWjwQT2GuWUxXic9UxTD1JhI+aOq9qpcDJs/0Owfk9e+8RnnDd7tdLN BWuBMeOTWLZp9yqMsBybkmN3V2tRWMl5h2PljNVyTtwkPCRpCoaxXReMBCWkbv3tGu ziOYN2mWHlm2qSeXmarT0ngnioU6Dqnhi2GWetls=
- In-reply-to: <20190814093748.u3pkdzrixmtunnt7@chaz.gmail.com>
- List-help: <mailto:zsh-workers-help@zsh.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:zsh-workers@zsh.org>
- List-unsubscribe: <mailto:zsh-workers-unsubscribe@zsh.org>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <2154283D-97B8-436B-8CC5-40624C11F356@icloud.com> <CGME20190814093844epcas2p44f875d2a2dd79067539d55e34fed4ae2@epcas2p4.samsung.com> <20190814093748.u3pkdzrixmtunnt7@chaz.gmail.com>
On Wed, 2019-08-14 at 10:37 +0100, Stephane Chazelas wrote:
> 2019-08-08 20:38:05 +0430, Aryn Starr:
> Now, that being said, as discussed on U&L it looks like a bug
> indeed and a shorter reproducer is:
>
> $ zsh -xc 'v=1; f() { local v; v=2 true; }; f; typeset -p v'
> +zsh:1> v=1
> +zsh:1> f
> +f:0> local v
> +f:0> v=2 +f:0> true
> +zsh:1> typeset -p v
> zsh:typeset:1: no such variable: v
>
> Most likely, that's the "v=2 true" (where "true" is a builtin) that ends up
> unsetting the "v" from the global scope.
Yes, the saved version of "v" that we restore after the builtin is
missing the pointer back to the version of v in the enclosing scope. So
it's not only not shown as set, it will leak memory.
This simply preserves that pointer in the copy, but this assumes we've
correctly blocked off the old parameter from being altered inside the
function scope --- if we haven't that preserved old pointer is going to
get us into trouble. However, if we haven't that's already a bug, so
this shouldn't make things worse.
pws
diff --git a/Src/params.c b/Src/params.c
index 1499e3a40..a253a9d8e 100644
--- a/Src/params.c
+++ b/Src/params.c
@@ -1124,8 +1124,10 @@ copyparam(Param tpm, Param pm, int fakecopy)
tpm->base = pm->base;
tpm->width = pm->width;
tpm->level = pm->level;
- if (!fakecopy)
+ if (!fakecopy) {
+ tpm->old = pm->old;
tpm->node.flags &= ~PM_SPECIAL;
+ }
switch (PM_TYPE(pm->node.flags)) {
case PM_SCALAR:
tpm->u.str = ztrdup(pm->gsu.s->getfn(pm));
diff --git a/Test/D04parameter.ztst b/Test/D04parameter.ztst
index 194c3e287..b6e85a9fe 100644
--- a/Test/D04parameter.ztst
+++ b/Test/D04parameter.ztst
@@ -2522,3 +2522,15 @@ F:behavior, see http://austingroupbugs.net/view.php?id=888
>trailing/slashes
>removed
>are/removed
+
+ foo=global-value
+ fn() {
+ local foo=function-value
+ foo=export-value true
+ print $foo
+ }
+ fn
+ print $foo
+0:Global variables are not trashed by "foo=bar builtin" (regression test)
+>function-value
+>global-value
Messages sorted by:
Reverse Date,
Date,
Thread,
Author