On Mon, Mar 4, 2024 at 9:43 PM Mikael Magnusson <mikachu@gmail.com> wrote:
>
> On 3/5/24, Bart Schaefer <schaefer@brasslantern.com> wrote:
> >
> >  When a _named reference_ is created with 'typeset -n', all uses of PNAME
> >  in assignments and expansions instead assign to or expand RNAME.  This
> >  also applies to 'unset PNAME' and to most subsequent uses of 'typeset'
> >  with the exception of 'typeset -n' and 'typeset +n'
>
> Is this possible to change? I feel like if "typeset myvar" (or "local
> myvar") cannot be depended on to create a local parameter, a lot of
> code will no longer be safe that previously was (in the sense that it
> doesn't break if calling code / the shell environmnet has certain
> parameters defined).

Yes, it's possible, and the attached patch does so, with doc update
and new tests.

The division of labor among bin_typeset(), typeset_single(), and
createparam() is a bit hard to follow (as in, it's not really much of
a "division" at all).

On Mon, Mar 4, 2024 at 10:31 PM Stephane Chazelas <stephane@chazelas.org> wrote:
>
> See also:
>
> $ nameref action=PS1
> $ zmv -n '*' '$f.back'
> zsh: segmentation fault  ./Src/zsh

A simpler reproducer:

% typeset -n foo=PS1
% () { local foo; foo=xx }
==1113679== Invalid read of size 8
==1113679==    at 0x1A16E1: assignstrvalue (params.c:2684)

This patch fixes that, and one other potential crash that valgrind
complains about:

% typeset -n foo=bar
% typeset -n foo
==1113695== Invalid read of size 4
==1113695==    at 0x136041: bin_typeset (builtin.c:3137)

I'll go ahead and push this since there doesn't seem to be any
argument about the change in function and it fixes two crash bugs.