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.3 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 6993 invoked from network); 9 Feb 2023 23:08:02 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 9 Feb 2023 23:08:02 -0000 ARC-Seal: i=1; cv=none; a=rsa-sha256; d=zsh.org; s=rsa-20210803; t=1675984083; b=SDKuHpen+4ITDOwO+Gnn7GvxUJTgpHUTDPjglSRDd172Ac98Y6WkfwjQA7M48So1Y9WK0Bfx7+ H/RkAbOXdTI+Vf4viKT34COWgvaEB0+D/tvSJubqQNRGXNIOhP2hO6fwbBb2d1wikPcqOWrmgc ZlMlceWwRxloo+TZ9cX7Kz4iKwqHOiSNT+W0E+JmPtg0ePOh3RgTaXtKbm3e71OY7JzGMsu7dD 8jDmVwf/Vw0ogWtLwN1oE+B9wztUKRqdDa1x48Bv5w5rbELmv1gUAuHG7Q8f2Y8Em6f6nXZsfX Ke90d2xx8mEYLuIidHCNLwGO4qntdtOOiIRb/m+ORz0vhg==; ARC-Authentication-Results: i=1; zsh.org; iprev=pass (mail-ej1-f54.google.com) smtp.remote-ip=209.85.218.54; dkim=pass header.d=brasslantern-com.20210112.gappssmtp.com header.s=20210112 header.a=rsa-sha256; dmarc=none header.from=brasslantern.com; arc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=zsh.org; s=rsa-20210803; t=1675984083; bh=/mocVTfscEooHH6teYQ38MpUQ158Wy4zrUh4ovoQpiY=; h=List-Archive:List-Owner:List-Post:List-Unsubscribe:List-Subscribe:List-Help: List-Id:Sender:Content-Type:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:DKIM-Signature:DKIM-Signature; b=r8NNa3qRsVPu1KYQ0Ej1keCjMQwxDrpShWCWZHfSTlelzWlQ3t3jAhqLYzdTE/mA2GeDmzaNEP 8Cb7442y/BEkHMBgXug2wYi68Q+YH85AsN9DaAhP9e+AzoEauoj92XksZpZOsFrbRket8S1ayX /O1Sg1JYjqMMzYJUVci6oml7ViwT3URIRMYxUizyM8NM4eCH9eos1VELgTA6GCyVvhb/WabDUH Ltwa/XKuw9RJXHtZPl9tQsLDDw1k6Joq/iCX3ke5UGVTU2AIPq1mfGE2fj+McPHgtaYq21ykbw Fetffaqwkx9jufIcq4DiWTqQzM4Gz/ylwtG9chYG7R8CnQ==; 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:Content-Type:To:Subject:Message-ID: Date:From:In-Reply-To:References:MIME-Version:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=fl7hvxcJrUqY2vzKtV2hpPMaf/jD73v5Qgrv621YnEQ=; b=AmD7r7OJSaTnuq8qZg2cyDUVCe A9Pn+/rqSE+6kdMkTMKzfjsl14TpYHP8gswYpZFj1A2lGlzaidC3tGwIDknMun+TJ2etNyBd0yDeV U1sOo+OETNR2DM87/cYHBTUgSfjAm24E0vtPN7u/JkfJ7Eu/dCOZRRxx/Rd83cf778hlzBNbtZ0fd AbG2uT8LKM2ZlEyZ3Fs9MYTBlBOvRTaUIJ5uyjiuNfN/Gss9B5qNoXc/okDI6WDLg/u2B6/hkXhSL MH9qe5VUqua4C0fpCF5R0c7qNcbKsR0UnDmIM50sYXkH0nh/+1kmrRHryCHkWXR7LK1TrbZm0iJ2m m+mPotlQ==; Received: by zero.zsh.org with local id 1pQG1J-000EqD-Pi; Thu, 09 Feb 2023 23:08:01 +0000 Authentication-Results: zsh.org; iprev=pass (mail-ej1-f54.google.com) smtp.remote-ip=209.85.218.54; dkim=pass header.d=brasslantern-com.20210112.gappssmtp.com header.s=20210112 header.a=rsa-sha256; dmarc=none header.from=brasslantern.com; arc=none Received: from mail-ej1-f54.google.com ([209.85.218.54]:43766) by zero.zsh.org with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128) id 1pQG0h-000EWu-Ns; Thu, 09 Feb 2023 23:07:24 +0000 Received: by mail-ej1-f54.google.com with SMTP id c26so6422908ejz.10 for ; Thu, 09 Feb 2023 15:07:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20210112.gappssmtp.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=fl7hvxcJrUqY2vzKtV2hpPMaf/jD73v5Qgrv621YnEQ=; b=gc62ZJgF22pNaDuzrCfhTxQQnbeORaB4O3YUnJwNHLQxokcJdzjcjomYjKhy38Bp5K 5JARkCabsRS2zIePUEH2+T2cJYNPPCt5df0w3E5uYxzSWExYmva7xqU/9ZNXH5LBLjwi AhAFqT2GXCcr8VIuxYh0aan8BKZA5g6VqNqJEUTTn2hmAJ4+fCGEg4bv8jmg7hPccsTN iNU8FxsYAVa0bw4RVQS8Te4sqTloYQD28JccmjRAx6GJrVwEz03AUCnPeMuHy36i8LEj gd2TRYABPErqy0H0a43paJtPUmhvkQjS1e9/cY2dAkkUjU4ORZEmyfpw0KAfKD44j96E pAlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=fl7hvxcJrUqY2vzKtV2hpPMaf/jD73v5Qgrv621YnEQ=; b=HtF+9u6OKz2+kA+7tgRTWzcxbhOF4Byyf+NInYWD93dBED00WrrLiWPs62czgiMh5d Suyub4QqrOOX4r8/DBd+veQi2aAVf9UtHRZAFAYDwV6KiQ/3PSYd0Kv1a7xW3/9NsydE bhV+tcVLDuDvTR4VKT4rVms+4ulrYaCHjaQfv7aN/Zxb1bEfJdblZld/paZzGUVu+NaY VBXVjXMLSWpUfbBehGDdrneSmAYY9MSuo0SZeG/O0+dFsRsuxFzfGNs49RJdqjj5PQju t8eillF3DCioCEuyb4zO/6tqvMopycGqK3nzvofGFKwb8E23fSmoZ4MPoP91dJUl/yvq E6Zg== X-Gm-Message-State: AO0yUKVrJZDq5c0AgyMSVc8lkT1U12jWwR0toWaYzbjqwR9d+Kv0a+vP qjRXRTgGoxBCT1Bn0Mc7SXzDmdhMw13Ty18FSNBqebRUVlYTE7VS X-Google-Smtp-Source: AK7set/EaT70ernqXGezAvlgbCv179jS/cS3nQfd0IvDYQJx4e4k4AoJMn9++FW5c6sKWLqb5mN6PIQqUnGvVPxryxQ= X-Received: by 2002:a17:906:4dc7:b0:877:e1ef:e49a with SMTP id f7-20020a1709064dc700b00877e1efe49amr2881909ejw.147.1675984043217; Thu, 09 Feb 2023 15:07:23 -0800 (PST) MIME-Version: 1.0 References: <67689-1675827940.088548@BxvG.D9_b.7RzI> <12608-1675903622.800470@Xj82.e3y1.svhG> <66045-1675975796.128039@FBF_.0yMO.Y8fk> In-Reply-To: <66045-1675975796.128039@FBF_.0yMO.Y8fk> From: Bart Schaefer Date: Thu, 9 Feb 2023 15:07:11 -0800 Message-ID: Subject: Re: [PATCH 1/3]: Add named references To: Zsh hackers list Content-Type: text/plain; charset="UTF-8" X-Seq: 51390 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: On Thu, Feb 9, 2023 at 12:49 PM Oliver Kiddle wrote: > > The following is similar: > var=hello > typeset -n ref > () { > typeset var=x > ref=var > echo $ref > } > typeset -p ref > echo $ref > > This creates a reference to a variable at a deeper local level. Only in a pointers/refcounting implementation. With the assumption of dynamic scoping, it creates a reference to a name, where the scope search for the name starts at a lower level. If that name doesn't exist at that level (because the whole level doesn't exist any more), the search climbs up. So I get with set -x (and a couple of in-progress patches for looping references): +Src/zsh:15> var=hello +Src/zsh:16> typeset -n ref +Src/zsh:17> '(anon)' +(anon):1> typeset var=x +(anon):2> ref=var +(anon):3> echo x x +Src/zsh:22> typeset -p ref typeset -n ref=var +Src/zsh:23> echo hello hello If I add () { typeset var=y echo $ref () { typeset var=z echo $ref } } I get +Src/zsh:24> '(anon)' +(anon):0> typeset var=y +(anon):0> echo y y +(anon):1> '(anon)' +(anon):0> typeset var=z +(anon):0> echo y y > The best might be if ref returns to being > unset when the function returns but an error like ksh is fine too. I'm not sure how to do that without scanning the whole parameter table, but I agree it the above is a little puzzling. > Ksh prints "global reference cannot refer to local variable". At what point does that happen? Upon the assignment ref=var ? 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? > > The rule for a private should be that you always > > pass its value. > > I hadn't really thought about it that way, perhaps because ksh only > has private scoping and I'm used to writing in languages that only > have lexical scoping. Certainly if it is hard to implement, I have no > objection to this approach. ("This approach" meaning "no public refs to private vars"?) I haven't tried anything else yet to see how hard it might be. > We do lose some orthogonality in > that you can use a private with builtins that take variable names like > read, compadd and printf (-v). Wrappers of those would have an added > limitation. That's true of private already, isn't it? > 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? > It isn't about the positionals being special but that it is useful to be > able to write a function that exposes an interface similar to read where > a variable can be named as a parameter. Ksh's making $1, $2.. special > on the rhs of typeset -n really is very ugly. This works for my code in current state: % var=GLOBAL % typeset -n ref=var % f() { function> typeset -n ref=$1 function> print $ref function> ref=LOCAL function> } % f ref GLOBAL % print $ref LOCAL % > > f2 \&var > > My intention with that suggestion is that you'd only do that to refer to > $var from the scope of f1's caller. So in practice that'd sooner be > something like \&$3. For this, it'd be just `f2 var` and f2() would > declare `private -n mine=\&1` Yeah, I don't like the idea that a called function can arbitrarily grab parameters from its caller just by sticking & in front. Caller needs to do do something (even if only make "normal" use of dynamic scope) to make the parameter "grabbable". > > With a hash that's just: > > > > typeset -n ref > > for ref in 'hash[(e)'${(k)^hash[(R)?*]}']'; do ... > > "just"!? Hah! Point was that it's do-able without "for"-context-sensitive special subscript semantics. I think it would be strange for ary=( 1 2 3 4 5 ) typeset -n ref='ary[*] ref=( a b c) to produce something different than ary=( 1 2 3 4 5 ) typeset -n ref for ref in 'ary{*]'; do ref=( a b c ); done > > > And it could be wise to limit what can be done as part of the > > > subscript evaluation to avoid a CVE similar to the last one. > > > > validate_refname() is calling parse_subscript() ... would further > > examination of the accepted string be sufficient, or something more > > needed? I think the greatest danger is of creating an infinite > > recursion, which can't really be caught in advance. > > So if a function gets the target of a nameref from untrusted input the > function writer needs to know to validate it No, I meant, would examining the subscript string in the C code be sufficient. > This should be an error perhaps: > > typeset -n ref=arr[1][2] Why? ${ary[1][2]} isn't an error, it's the 2nd character of the first word in $ary. You can keep throwing subscripts on there as long as the resulting substrings can be indexed-into. print ${ary[1][3,9][4]} # etc. > Currently it isn't possible to create a reference fo $!, $?, $@, $+, $# > and $$. If easy to add, there would be no harm in them. You can make references to argv and ARGC, but they always refer to the current argv/ARGC because of the aforementioned implementation of positionals as C locals. $* $@ $# would have the same issues. The others would all have to be special-cased individually. What is $+ ? Do you mean $- ?