From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6240 invoked by alias); 24 Nov 2015 04:43:50 -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: X-Seq: 37207 Received: (qmail 13348 invoked from network); 24 Nov 2015 04:43:49 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_DKIM_INVALID autolearn=ham autolearn_force=no version=3.4.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:date:in-reply-to:comments:references:to:subject :mime-version:content-type; bh=uuanGq18wrD7E49FMmdMXWwwkwzFQwI36/Nvh5UmMw4=; b=MbwwtL0NI//XutYcphHhAlHbfe0rmwI/7YHfURb3VYNatHQPNF+nBaRQLi9EqrMfC7 MQx0Xdptkie8QI1mMfR92DgC4k/bmVnIU/+H9jAYOU/WaIcXqy4nw0lZyvouMVDV29PO iSKRwIyf3jdb4oXOeuxu4eL+46Gj5Kj+PNB87VIMaDHnhUpb++DQ/zcjUsSrPRPV0jCC ph/ktwNPwoa8vZ9Qg2NqV1U2/L39ChPSHF1DMR3nqAA1kZInRueDxK4PhZJz1YRQW8GT 5S0pW5HRlrsLCmGiZg/TVHMcq7wy4YC9tF5N7yEB5Z40p20Qk0hw6l34BZ15yvb8h0sg G5yA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:to:subject:mime-version:content-type; bh=uuanGq18wrD7E49FMmdMXWwwkwzFQwI36/Nvh5UmMw4=; b=HlzBA9TgJCkNxfY+dxuSpBCci9MDfJt5i9OEDBDMJ/ZCtDoS2X31FAxzC8IJQHCovQ ot+AjW3DzrK+1qgaSHIgX0U+YdV2FdtR4XQpT4LbF2kUIgknQMYN8ggQjVDMR9IP0T5c AZ6v8enyzCSzRbjz5Ix6KE3Q0z/bH+plI8V3EuNbbucOlF+UpZJhKUjNEWBbsGr7VoZy JErIuZrysDYZUnEmiApgY7jJoFlAQzuLpU6r2oxpafV9BQ6fztZFkTMkZgQHWi8WcY7+ tEO/LdXsCvsVxPlwhaK5b3jCouYUCo3aCA9hTkM+wRJ83mD7NUrPa8o43+Eb2g7A7/up dLYQ== X-Gm-Message-State: ALoCoQmLbv2Bbcn+N/O0PtVSoOXpLfQtVcTgR5Kdwrp1RaMFpj9N0/bZQP2GaU18bRgsJqX2zyqn X-Received: by 10.66.100.166 with SMTP id ez6mr40197179pab.49.1448340227009; Mon, 23 Nov 2015 20:43:47 -0800 (PST) From: Bart Schaefer Message-Id: <151123204351.ZM23160@torch.brasslantern.com> Date: Mon, 23 Nov 2015 20:43:51 -0800 In-Reply-To: <20151123154916.7ef3406e@pwslap01u.europe.root.pri> Comments: In reply to Peter Stephenson "Re: Possibly excessive WARN_CREATE_GLOBAL" (Nov 23, 3:49pm) References: <201511221915.tAMJFbFW006908@localhost.localdomain> <151122123028.ZM11174@torch.brasslantern.com> <20151123154916.7ef3406e@pwslap01u.europe.root.pri> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: Possibly excessive WARN_CREATE_GLOBAL MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Nov 23, 3:49pm, Peter Stephenson wrote: } Subject: Re: Possibly excessive WARN_CREATE_GLOBAL } } On Sun, 22 Nov 2015 12:30:28 -0800 } Bart Schaefer wrote: } > We come into createparam() and discover at line 878 that the parameter } > already exists, which is what we want, but in spite of it being flagged } > PM_SPECIAL|PM_REMOVABLE all createparam() does is toggle off the PM_UNSET } > flag, which seems dubious. } } Being special and removable shouldn't stop you re-enabling the parameter } --- this test has nothing to do with scope here, it's just recreating } the parameter as you've asked it to do. (It's not checking PM_HIDE here, } or you might think that was useful.) It took me a while to figure out how to explain why I think this is dubious, but finally decided it comes down to this: Toggling PM_UNSET off here without calling the GSU setfn implicitly provides a default value for the parameter, which is sort of OK for normal parameters but wrong for PM_SPECIAL. If nothing else, it means the getfn has to be prepared to return something even if the setfn has never been called. (Of course theoretically the setfn was called with NULL before the PM_UNSET flag was set in the first place, but also theoretically the setfn could make use of the state of PM_UNSET at the time of call.) Unfortunately none of the standard setfn do anything with PM_UNSET; they all rely on it having been cleared by createparam(), so a change there could have far-reaching effects. Not something to do while a release is imminent. } Perhaps what it should be doing is creating a new one in the inner } scope that hides the private one as the least bad effect. What should happen is that it creates a new one at global scope, and trips warncreateglobal if necessary. Which DOES happen if the one at global scope was previously assigned and/or explicitly declared. The difficulty only arises when the private parameter is at the outermost scope where any parameter of that name can be found. } Or, possibly in this case, it should be an error that tells you need to } use "typeset" to override a private variable in a local scope. It might be possible to pull this off, but probably not until it's too late for the PM_UNSET flag to have been (in)correctly handled.