Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: Possibly excessive WARN_CREATE_GLOBAL



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



Messages sorted by: Reverse Date, Date, Thread, Author