Re: Speaking of dangerous referents

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Sun, Feb 12, 2023 at 12:00 AM Oliver Kiddle <opk@xxxxxxx> wrote:
>
> Bart Schaefer wrote:
> > % empty=()
> > % loop='empty[${(P)loop}]'
> > % print ${(P)loop}
> > zsh: segmentation fault (core dumped)  zsh -f
>
> And in 51399 on namerefs:
> > Circular references hidden inside subscripts end up expanding to empty
> > string, as do command substitutions with the NO_EXEC trick.
>
> That surprises me. I can't see any executions occurring.

I apologize, the reference to NO_EXEC only applies to the clause about
command substitutions.  The circular references are handled by using
tagging to detect/abort the loop during nameref resolution.  I'm
uncertain whether a similar approach could be used for (P) and haven't
dug into it, I didn't want to mix a patch for that into the patches
for namerefs.

> Would making
> (P) a little safer by applying the NO_EXEC trick to it too fix that seg
> fault. Or did you have a different fix in mind?

It wouldn't and I didn't, at least not yet.  It would have to be
something along the lines of the "math recursion limit exceeded"
handling.  There are two or three other places in the code where there
are comments rejecting arbitrary limits on recursion so this might be
something we don't want to fix.

> Making (P) safer could be another use for the FUTURE option I suggested
> in the final paragraph of 51281 - perhaps very few people (if any) were
> still reading at that point so it may have been overlooked.

It would be helpful to know whether any of the uses of (P) in the
existing contributed and completion functions etc. actually rely on
expanding command substitutions.  It would be pretty unlikely that
they rely on self-reference.