From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from primenet.com.au (ns1.primenet.com.au [203.24.36.2]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id a4d0b3bb for ; Wed, 14 Aug 2019 15:13:03 +0000 (UTC) Received: (qmail 7687 invoked by alias); 14 Aug 2019 15:12:56 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: List-Unsubscribe: X-Seq: 44665 Received: (qmail 8656 invoked by uid 1010); 14 Aug 2019 15:12:56 -0000 X-Qmail-Scanner-Diagnostics: from mail-oi1-f181.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.101.2/25538. spamassassin: 3.4.2. Clear:RC:0(209.85.167.181):SA:0(-2.0/5.0):. Processed in 2.700344 secs); 14 Aug 2019 15:12:56 -0000 X-Envelope-From: mikachu@gmail.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.167.181 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CBbhzT72AnDYvSXyhLB9x7EDksMnbX01yNGLTnNfpf8=; b=rrLky2JSmBtRDftsIFOJh8TMw2zqfai3XyxKPk8mURfYuVpMa1YtYykqxcP5z4pF0D L2iGH4kzkWk4kT8S0iKpSyOGqVq/ZNrwlHxC4Qqkeeg8kk39tPOYF/GZjBB5cOZpQ//0 mjx0d/JCZT7B0jNd2I5n7nxf1YiSc2tWa+J3Sd76QcbKKVLGlKc3NyDCxz6kIMs5EyzY hF4MWW2ESileis2IhzjvOy+n2ITaSB9D4I/KiUqxlQb6kIgMjWIDhM3ukDZk8Ermg9u+ 41HIGxiMHg/OXTAwZbwkTzrDuISMQJR/AXb1JyRSLdVmT2V9ftY04i5YQwhpQ665ixen Xpwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CBbhzT72AnDYvSXyhLB9x7EDksMnbX01yNGLTnNfpf8=; b=VHIgS76QBNb+xiRwuY5XlsTOr3IT4Fcd7RsP32v4mGtn9bkXT41rrqLCwoj9BQxLB7 3qZx/LwjO/7YlimHpZiIsll9XP3xviY943Yn94NfUml1wSXEjkW3vinUANQOvKT7bWS2 illbcsdE3C92TFnCCvsmjv3ijViMpgkJpi4+WIyZoGyQXRMC5Vtp6RQd8CIcNBbfA6M1 2vM3LHQsOaCP8kXDNe5gzSae1RniMjUPf+rHms1kras2FZRNOvJyPCbB4Qa5miCH3NCC bAYkXXOgkun1EyycCkqVAfgXBYUNA8Pi7hH4kS9iOMCm6LCmazD0NiBKbC7y2Fm4l03Z kCpA== X-Gm-Message-State: APjAAAWZoHImAu2L3kdmE+Sa6qmE3sMiy5the8z5Ig4weuqpGZR5m2pd pYmlPyDBjYo0nxVY/+A2eunLSB6mLzMfeUBXHz0= X-Google-Smtp-Source: APXvYqx0mXbG/cMHIPIkIS1k1UpraQPCw947MPHT126sibgG01kuIseh9rsJn+WteczsUPuNzXaMTzfQhxjLFEw/hT4= X-Received: by 2002:a02:3e86:: with SMTP id s128mr3890656jas.14.1565795540004; Wed, 14 Aug 2019 08:12:20 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <1565791473.4796.6.camel@samsung.com> References: <2154283D-97B8-436B-8CC5-40624C11F356@icloud.com> <20190814093748.u3pkdzrixmtunnt7@chaz.gmail.com> <1565791473.4796.6.camel@samsung.com> From: Mikael Magnusson Date: Wed, 14 Aug 2019 17:12:19 +0200 Message-ID: Subject: Re: Bug Report: Variable becomes unset without reason To: Peter Stephenson Cc: zsh-workers@zsh.org Content-Type: text/plain; charset="UTF-8" On 8/14/19, Peter Stephenson wrote: > 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. This got me thinking about related stuff. I guess these results are expected, maybe even at best unspecified? % foo=initial; foo=bar printf -v foo hello; echo $foo initial % set hi; argv= set hello; echo $1 hi % set a b c; argv= shift; echo $@ a b c % a=1; a=5 typeset a=3 b=7; echo $a$b 17 -- Mikael Magnusson