Zsh Mailing List Archive
Messages sorted by:
Re: Possibly excessive WARN_CREATE_GLOBAL
- X-seq: zsh-workers 37207
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxx
- Subject: Re: Possibly excessive WARN_CREATE_GLOBAL
- Date: Mon, 23 Nov 2015 20:43:51 -0800
- 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==
- In-reply-to: <firstname.lastname@example.org>
- List-help: <mailto:email@example.com>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:firstname.lastname@example.org>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <201511221915.tAMJFbFW006908@localhost.localdomain> <151122123028.ZM11174@torch.brasslantern.com> <email@example.com>
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 <schaefer@xxxxxxxxxxxxxxxx> 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.
Messages sorted by: