From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28458 invoked by alias); 22 Nov 2015 18:28:02 -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: 37193 Received: (qmail 19827 invoked from network); 22 Nov 2015 18:28:00 -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-Originating-IP: [86.6.158.222] X-Spam: 0 X-Authority: v=2.1 cv=RLtOZNW+ c=1 sm=1 tr=0 a=2SBOh4l1h08DI0L+aujZyQ==:117 a=2SBOh4l1h08DI0L+aujZyQ==:17 a=NLZqzBF-AAAA:8 a=kj9zAlcOel0A:10 a=q2GGsy2AAAAA:8 a=OFpH3IrNHvncgW4JEGsA:9 a=CjuIK1q_8ugA:10 Date: Sun, 22 Nov 2015 18:27:55 +0000 From: Peter Stephenson To: Bart Schaefer Cc: zsh-workers@zsh.org Subject: Re: Possibly excessive WARN_CREATE_GLOBAL Message-ID: <20151122182755.2ad1cb72@ntlworld.com> In-Reply-To: <151122095213.ZM10080@torch.brasslantern.com> References: <151122095213.ZM10080@torch.brasslantern.com> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.28; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Sun, 22 Nov 2015 09:52:12 -0800 Bart Schaefer wrote: > However, do we want to be complaining about REPLY, reply, match, mbegin, > mend, MBEGIN, MEND, and BASH_REMATCH? Yes, those are exactly the ones where it's important we do --- in fact, match etc. were in my mind when I introduced the option, although at the time the warning didn't actually cover the usual cases of that. With most variables in functions, leaking isn't that important; you just get a randomly named variable in the outer scope. Those variables, on the other hand, are the ones most likely to be used in nested functions and in multiple ways within the same higher level function. For example, you match a pattern (setting "match" etc.), call another function that also uses the feature, then try to use $match in the outer function --- which is now misset. (Unfortunately, in this example we don't actually get a warning for the inner scope if the outer function had already localised the variable (and that outer use is the only one that would be reported if it didn't do so); however, if the inner function got used in another context, we would get the warning there. But I don't think that's relevant to the basic point. You could argue for a warning "variable created in outer scope", I suppose.) REPLY/reply are complicated by the fact you need to localise them only in an outer scope, but I'd argue that it's therefore even easier to forget so a warning is even more useful. If you're not worried about *those* variables polluting outer scope, therefore, it seems to me unlikely you're interested in the option at all. If we need to make exceptions, I think they're more likely to be connected to specific instances of setting variables internally. pws