From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from zero.zsh.org (zero.zsh.org [IPv6:2a02:898:31:0:48:4558:7a:7368]) by inbox.vuxu.org (Postfix) with ESMTP id 0584B21379 for ; Tue, 5 Mar 2024 09:19:17 +0100 (CET) ARC-Seal: i=1; cv=none; a=rsa-sha256; d=zsh.org; s=rsa-20210803; t=1709626757; b=efE9bGIaBSQ94/mlVwBMPv0hHzi8TSIYRgFNwass5TbaBycxCiQns1CCpN+Cmlb5g4NYd6T83N Wj8oyrz8rx10zfhenYs6OGY+uwjux4w1QzAr6aUm2ISzlCQC2Iw//LGnvGIYk3yOkf8WcpTLBl XJ96np+2V9ZXZCj7YNncLuFm8R6clM2yJYRliOLF49QHp0nOGx4BuP6u2bvnN6B1NR2eMC1b/U 4miu43UJq3yVyR1QE2m3GZdi8KibZYkhwDglAs73kpMWcLyQs1bzZ+7v3B0s0nFC0kVp38wjdd L5QJ50++26OsX2X25Y9AjcnCl/+TRWJmn+Dz9SXXkvV7Yg==; ARC-Authentication-Results: i=1; zsh.org; iprev=pass (relay3-d.mail.gandi.net) smtp.remote-ip=217.70.183.195; dmarc=none header.from=chazelas.org; arc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=zsh.org; s=rsa-20210803; t=1709626757; bh=G4zHLPIETH/xAE0GGdKU8PjSK7k0If6d/Vi+cVl6PIg=; h=List-Archive:List-Owner:List-Post:List-Unsubscribe:List-Subscribe:List-Help: List-Id:Sender:In-Reply-To:Content-Transfer-Encoding:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:DKIM-Signature; b=MDhUiYTdoYpUtMuyBFqTRHfsML+XUjokmka+FO5LdF7t2GOfaoL1QjMq4lpAQ5Op/aJH8EoOSJ ERJNLgbjLEzuVW3PbQ1NjCnUSnu795nEAySYenF6jFVkSea+HVAxA/ryrDZ8rxs0HJVv7PYj95 DN6Hu/u9HzZpMMduoE8RPQOg7/zRfPbXLtl98MJ4Ac37DtGYQE32OZ9GzfqmieyY8FV2PyUmpj ph0CcTr5Y6Ad3QHbm+VP6DjWKPTWidrV7GOs9YpDszIlJZFa41XgfAgxQJlXR47UOKj9VEBOgh YH8Lb/+/b4hhGzv5Zi6JRuoE73aZ2wnI88cEc0UXqJqacQ==; 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:In-Reply-To:Content-Transfer-Encoding :Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender :Resent-To:Resent-Cc:Resent-Message-ID; bh=C88cqloSgDum6T6Uc4Gb5g6+baqJ9lGU47UyOq6fPiw=; b=IQss5mtuHMHWb/Y3QJApvO50NX vaYqboK/MyqiB1MyU7V7WR2WIIz8sF82f62ZGnhUuxQKiM+IdX2wX6zLA9eluycCPc/FRDqnTuxjB iKU8GSd0VHZNhnk2LZjllwK7I6ZOi6zDyKoz3QTeEFF3QpGOu8D3Kokls3PNtNgsj7RRRlVGFP62P 16B4pP6sSHtOySpOkoZqm0d7O59gQ2Cikoc2OBF4sg37hx6040xiQmwe/i2qTgaxku5k+WDACC4IA yexR4b2FphKgklQpJgjrE5xTtW79kgzlNbbQqry6G9l4dJYZBzRo2C6YSios8D8NBKZGH1YLyeZPW oDPQGDRA==; Received: by zero.zsh.org with local id 1rhQ16-0000zr-Sk; Tue, 05 Mar 2024 08:19:16 +0000 Authentication-Results: zsh.org; iprev=pass (relay3-d.mail.gandi.net) smtp.remote-ip=217.70.183.195; dmarc=none header.from=chazelas.org; arc=none Received: from relay3-d.mail.gandi.net ([217.70.183.195]:43189) by zero.zsh.org with esmtps (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1rhQ0r-0000i3-EY; Tue, 05 Mar 2024 08:19:02 +0000 Received: by mail.gandi.net (Postfix) with ESMTPSA id 2A1B960004; Tue, 5 Mar 2024 08:18:59 +0000 (UTC) Date: Tue, 5 Mar 2024 08:18:59 +0000 From: Stephane Chazelas To: Bart Schaefer Cc: Zsh hackers list Subject: Re: [PATCH] Fix crash on unset-through-nameref Message-ID: <20240305081859.r3qwiyduk2wgkdby@chazelas.org> Mail-Followup-To: Bart Schaefer , Zsh hackers list References: <20240304062914.kn6wquvgog3lefom@chazelas.org> <20240304193409.lv725ah6eifiazzx@chazelas.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-GND-Sasl: stephane@chazelas.org X-Seq: 52683 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: 2024-03-04 15:18:06 -0800, Bart Schaefer: > On Mon, Mar 4, 2024 at 11:34 AM Stephane Chazelas wrote: > > > > 2024-03-04 00:39:30 -0800, Bart Schaefer: > > > > > > Try removing this line from the patch: > > > > > > + pm->node.flags |= PM_DECLARED; > > > > $ ./Src/zsh -c 'myunset() { typeset -n v=$1; unset v; }; export x=1; myunset x; typeset -p x; x=2; typeset -p x' > > export x=2 > > > > It still retained its export attribute. > > This gets messy because POSIX says that's exactly what's supposed to > happen when unsetting an export, even though in native zsh it normally > doesn't work that way. No, I think you're confusing with: export foo Which is meant to give the export attribute to foo without giving it a value (so the variable will end up in the environment of executed command if ever its assigned in the future but not until then). unset foo (or better unset -v foo as POSIX allows bash's behaviour where that could unset a function instead) is required to clear the value and export attribute. unset is the only way to unexport a variable in POSIX shells. > You'll note it also didn't say > typeset: no such variable: x > > ... because there is no provision in the parameter implementation for > a global to occupy a table slot and yet to appear not to exist. > > This is one of the reasons your desire for "create it an as unset at > the time a nameref mentions it" has inherent problems. I was suggesting a "unset (and undeclared then) but named ref" (and refcount if needed for garbage collection) flag for that in a separate message, but I have no idea whether that'd be sufficient or feasible. I hate to say this but it seems to me that if this kind of issue is not fixable, then it would likely be preferable (from a consistency PoV at least) to go for bash/mksh dumber approaches where namerefs are just plain scalar variables containing the name of another variable (or other lvalue) and having the target variable resolved any time the nameref is assigned/referenced (in whatever scope that happens to be). You'd still need to namespace your variables in functions using namerefs, even more so, but at least it would be more consistent and we wouldn't have to list all the special cases that work or don't work in the documentation BTW, speaking of "other lvalue", see also: $ ksh -c 'typeset -n a="b[n++]"; typeset -p n; b=(); a=a a=b a=c; typeset -p b n' n=2 typeset -a b=([1]=c) n=2 $ mksh -c 'typeset -n a="b[n++]"; typeset -p n; b=(); a=a a=b a=c; typeset -p b n' set -A b typeset b[0]=a typeset b[2]=b typeset b[4]=c typeset n=6 $ bash -c 'typeset -n a="b[n++]"; typeset -p n; b=(); a=a a=b a=c; typeset -p b n' bash: line 1: typeset: n: not found declare -a b=([0]="a" [1]="b" [2]="c") declare -- n="3" $ ./Src/zsh -c 'typeset -n a="b[n++]"; typeset -p n; b=(); a=a a=b a=c; typeset -p b n' zsh:typeset:1: no such variable: n typeset -a b=( a '' b '' c ) typeset -i n=6 Which suggests the lvalue is still evaluated by zsh at every assignment at least. (see also https://unix.stackexchange.com/questions/640687/prevent-command-substitution-from-running-when-declaring-a-variable/640695#640695 where namerefs are abused to have a variable with a dynamic value). -- Stephane