Re: [PATCH] Fix crash on unset-through-nameref

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Tue, Mar 5, 2024 at 11:38 AM Stephane Chazelas <stephane@xxxxxxxxxxxx> wrote:
>
> 2024-03-05 10:42:18 -0800, Bart Schaefer:
> [...]
> > > 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
> >
> > That is in fact exactly how it works, with the addition now that -u
> > makes it skip upward one scope before resolving.
>
> Well, not in the:
>
> $ ./Src/zsh -c 'f() { typeset -n ref=var; local var=1; echo $ref; }; var=0; f'
> 0

OK, yes, there is one extra attempt to resolve at the time of
declaration, and it "remembers" the scope where it completed the
resolve and always goes first to that scope again.

> But is IMO somewhat inconsistent with:
>
> $ ./Src/zsh -c 'f() { nameref ref=var; local var=1; echo $ref; }; f'
> 1

Sorry, your example is confusing me.  "nameref" is only available when
the zsh/ksh93 module is loaded.  What's actually happening here, and
why do you never use -fc to prevent dotfiles from being read?

I think you're referring to the difference between
  var=0; f
and simply
  f
In the latter case, "the scope where it completed the resolve" is the
local scope because no parameter in a surrounding scope exists.  If
you assign to such a nameref, it "goes first to that scope", and if it
still finds nothing, climbs up to global scope (because implicitly
"finds nothing" at any local scope means there can't be that name at
global scope).

It's consistent with how $var / var=x would work if you never declared
anything, and consistent with ${(P)ptr} / ${(P)ptr::=x} when ptr is a
plain scalar.  The difference is when the ref has already found
something, which seems like the intended difference if you're using a
reference in the first place.