Re: [PATCH 1/3]: Add named references

[Oliver Kiddle <opk@zsh.org>]

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 <schaefer@brasslantern.com> 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