Re: Possibly excessive WARN_CREATE_GLOBAL

[Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx>]

On Sun, 22 Nov 2015 09:52:12 -0800
Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> 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