Re: A solution to fix hidden references in reference chains

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Sun, Mar 22, 2026 at 6:15 PM Philippe Altherr
<philippe.altherr@xxxxxxxxx> wrote:
>>
>> But you can't change a named reference into something else that way.
>> Even "unset -n" doesn't remove the nameref-ness of the surrounding
>> scope parameter.
>
> Yep but I was working on a fix for this issue. I have now sent the patch, see workers/54236.

This is exactly the thing I meant was a conflict.  I'm not convinced
workers/54236 is correct in this regard.

>> > - Ref added to a scope list is now an integer with base=N
>>
>> Per above, I think this is actually impossible, at least at present?
>
> Once workers/54236 is committed all of that should become possible.

Again, should it?  (Asking others, not Philippe.)  Related:

> - In workers/54236, I had to add many checks for PM_UNSET and PM_DECLARED. Most of these would not be needed if whenever a local variable is unset all its flags were cleared and replaced with PM_UNSET. This would guarantee that if a parameter has a type flag (one of PM_ARRAY, PM_INTEGER, PM_NAMEREF, ...) then it's for sure a still alive parameter of that type. Currently, you should always check for the presence of the type flag and the absence of PM_UNSET or the presence of PM_DECLARED, which is rather verbose and very error prone. Do you see any reason why flags should NOT be cleared when a parameter is unset? Afaik, there exists no mechanism that allows undeleting an unset parameter. So I don't see any reason why flags would need to be kept after a parameter is unset.

I don't recall all the details (again, other readers?) but my
recollection is that there's a POSIXy issue here.  E.g., an exported
parameter remains exported even if unset (so re-assigning it updates
the environment), and I believe numeric types are supposed to retain
their properties across unset.  This is why I wonder whether
references ought also to retain reference-ness across unset.

> - I wonder whether we would be better served if PM_DECLARED was replaced with a PM_NULL

We had that argument at some length before PM_DECLARED was introduced,
and decided against PM_NULL, and I'm not excited about rehashing the
topic.

> - Bart, you once suggested that dereferencing not-yet-initialized references ought to trigger an error. Currently such references need to be handled in several places and, when they are part of assignments, they trigger various kinds of errors/warnings that may not necessarily make much sense to end users. My impression is that things could be simpler and more uniform if dereferencing a not-yet-initialized reference would always trigger an error. I will try to write a patch that does that,

There, we need to consider what happens with ksh.