From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10432 invoked by alias); 23 Nov 2015 15:49:23 -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: 37204 Received: (qmail 9042 invoked from network); 23 Nov 2015 15:49:22 -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 autolearn=ham autolearn_force=no version=3.4.0 X-AuditID: cbfec7f5-f79b16d000005389-68-5653357f2185 Date: Mon, 23 Nov 2015 15:49:16 +0000 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: Possibly excessive WARN_CREATE_GLOBAL Message-id: <20151123154916.7ef3406e@pwslap01u.europe.root.pri> In-reply-to: <151122123028.ZM11174@torch.brasslantern.com> References: <201511221915.tAMJFbFW006908@localhost.localdomain> <151122123028.ZM11174@torch.brasslantern.com> Organization: Samsung Cambridge Solution Centre X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.0; i386-redhat-linux-gnu) MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrILMWRmVeSWpSXmKPExsVy+t/xa7r1psFhBo+ua1ocbH7I5MDoserg B6YAxigum5TUnMyy1CJ9uwSujOfLHzAWNAlU7H7YzNbAeJuni5GTQ0LARKJnx2Q2CFtM4sK9 9UA2F4eQwFJGiYd7ljNBODOYJGa8uMEI4ZxjlHh3cBVU2VlGiW+nHoH1swioSjycsZIdxGYT MJSYumk2I4gtIiAucXbteRYQW1jASOL79bNgNq+AvcSPh9+YQGxOASuJla8OMoPYQgL5Enem bAKz+QX0Ja7+/cQEcZ+9xMwrZxghegUlfky+BzaHWUBLYvO2JlYIW15i85q3UHPUJW7c3c0+ gVF4FpKWWUhaZiFpWcDIvIpRNLU0uaA4KT3XSK84Mbe4NC9dLzk/dxMjJKC/7mBceszqEKMA B6MSD6+GflCYEGtiWXFl7iFGCQ5mJRFeE+PgMCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8M3e9 DxESSE8sSc1OTS1ILYLJMnFwSjUwblUxfvgr93HXlvg8zhDPC2l8lydmmXDsa9byeCZSa3ls VpD2RS8W2wm8uz85nV6RIPMh4d+b/t7/139lXtDt8vzCxLpOW7S19l1GtNKvmx0mU2S+xl49 8lLRsj5zy7vb1dKeRWIiS1Y9NN/24dj6yB8rChf/21ms9z+T8azr6zk6QomyJqyTlFiKMxIN tZiLihMBDGVB6mQCAAA= On Sun, 22 Nov 2015 12:30:28 -0800 Bart Schaefer wrote: > On Nov 22, 7:15pm, Peter Stephenson wrote: > } > } Or do you mean it doesn't actually get set *at all*? That should surely > } trigger an error immediately in the inner scope, shouldn't it? > > It doesn't get set at all. > > 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.) 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. 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. So this is a stronger and more special version of the option, but depending on the fact you've already opted in to new syntax by loading the private module. That might be good enough, but for top marks we'd probably need to be surer that's what's really happened. > (And *then* it tests PM_RESTRICTED, which it seems to me ought to come > first? That's not related to this thread, but I wouldn't think you > should be able to change the unset-ness of a restricted parameter.) Quite possibly. > Then we enter fetchvalue() at line 2926, which correctly returns that the > parameter does not have a value, and assignaparam() silently surrenders at > line 2929. Maybe there should always be an error at that point, I don't > know how else we might get there. Certainly you've asked it to assign a value and it hasn't, which seems like an error. The assumption may previously have been there was already an error. pws