From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 15911 invoked from network); 11 Feb 2023 07:02:43 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 11 Feb 2023 07:02:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=zsh.org; s=rsa-20210803; h=List-Archive:List-Owner:List-Post:List-Unsubscribe: List-Subscribe:List-Help:List-Id:Sender:Message-ID:Date:Content-ID: Content-Type:MIME-Version:Subject:To:References:From:In-reply-to:cc:Reply-To: Content-Transfer-Encoding:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=iD4hoG4bs1eQg83JTNjqHfGpyUQKwPcgynBQEPARQpQ=; b=dJnAL2yIQnp8FDoEnYZaOozxw8 amBKNSFFRq2YDtLswNLJl6bOKrNCGxkqQWzCqR7UfpLOCwUiE/UdbujHp3CRoB0Pke7xTvJ9zmSB4 UZLAy7442IDVV363flN6I1lExSLMN7oM72S/ww5CMOX/pHWgI3lvihcrgAuGtL+S48HoIBP1s8DtV CyeIteMTbJWPORamBWB/9FDzt2VrcHQB/r7ZdBCZ9GqsOGwRStfjUkYnjnLKKwZl6kCHzkDW80LEq w6AZefc2U2rlId0e17jUUtle6GrFRajZ8KBT61QuGd3dhTPCt5UtM5w+nJWrhCQGjZUXDc/G/QqAh uFBv0G2A==; Received: by zero.zsh.org with local id 1pQjuD-000FHT-Qz; Sat, 11 Feb 2023 07:02:41 +0000 Received: by zero.zsh.org with esmtpsa (TLS1.3:TLS_AES_256_GCM_SHA384:256) id 1pQjte-000Ewz-RQ; Sat, 11 Feb 2023 07:02:06 +0000 Received: from [192.168.178.21] (helo=hydra) by mail.kiddle.eu with esmtp(Exim 4.95) (envelope-from ) id 1pQjtd-000Aat-3o; Sat, 11 Feb 2023 08:02:05 +0100 cc: Zsh hackers list In-reply-to: From: Oliver Kiddle References: <67689-1675827940.088548@BxvG.D9_b.7RzI> <12608-1675903622.800470@Xj82.e3y1.svhG> <66045-1675975796.128039@FBF_.0yMO.Y8fk> To: Bart Schaefer Subject: Re: [PATCH 1/3]: Add named references MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <40725.1676098925.1@hydra> Date: Sat, 11 Feb 2023 08:02:05 +0100 Message-ID: <40726-1676098925.110777@U2kb.d0Pd.I9ml> X-Seq: 51398 Archived-At: X-Loop: zsh-workers@zsh.org Errors-To: zsh-workers-owner@zsh.org Precedence: list Precedence: bulk Sender: zsh-workers-request@zsh.org X-no-archive: yes List-Id: List-Help: , List-Subscribe: , List-Unsubscribe: , List-Post: List-Owner: List-Archive: Bart Schaefer wrote: > Closing in on this, I think ... remaining decisions on which input > would be appreciated: > > On Thu, Feb 9, 2023 at 3:07 PM Bart Schaefer wrote: > > > > > Ksh prints "global reference cannot refer to local variable". > > > > At what point does that happen? Upon the assignment ref=var ? > > At the moment, just toying with this, I have it erroring when > EMULATE_KSH, printing a warning when WARN_NESTED_VAR, and otherwise > silently creating the down-scope reference. Thoughts? Perhaps > WARN_CREATE_GLOBAL would actually be better here, or maybe check for > either one. I'd make it a fatal error unconditionally. I don't like it if the target of a nameref can switch to something else following a return. I'd be fine with the reference becoming unset at the time of the return if it refers to a variable that is going out of scope. Can that be done as part of the same code that drops the local variables? (I'm guessing it is easy for local but hard for private) The mention of WARN_NESTED_VAR raises something else. Surely a reference should disable that warning: toplevel() { local foo="in fn" nested } nested() { typeset -n ref=foo ref="in nested" } setopt warn_nested_var toplevel nested:2: scalar parameter foo set in enclosing scope in function nested > > Relatedly, what should happen on any failed assignment? E.g. > > > > typeset -n xy yx > > xy=yx # OK so far > > yx=xy # Oops, invalid loop > > > > Should yx become unset, or should it remain a nameref with no referent? > > This probably doesn't matter except at the command line as the > referent loop is otherwise fatal. Current code even allows: typeset -n ref ref=ref I'd suggest that we need the self-reference check whenever assigning to a reference. But that entails evaluation of a subscript. > > > When relying only on dynamic scoping, it would be good practice to > > > define all the namerefs to passed parameters as early as possible in a > > > function to reduce the risk of a name clash. > > > > If you were going to put that in the doc, where would it go? Do we to put recommended good practices in the doc at all as opposed to it being a terse description of the functionality. I'd prefer it out of the way with examples rather than adding fluff to the places you list. I'd also consider it bad practice not to always assign a reference when creating it. > > > It might deprive us of many clever tricks but parse_subscript() could > > > gain a flag to disable anything questionable like command substitution > > > and math evaluation side-effects. > > parse_subscript() is already a bit of a hack, it sets up its own > context and invokes the lexer. A flag such as that would, I think, > require plugging in an alternate lexer, hence my question about doing > a simpler examination of the string. That's not as robust but certainly an option. The temporary use of NOEXEC that you mention in the other message certainly goes a long way to alleviating security concerns. Oliver