The flags are assigned at the end of createparam(), overwriting
whatever the old flags were. PM_NAMEREF is checked too early for
that, to cause the assignment to go through to the referent instead.
So that has to be cleared before we reach createparam().
On Tue, Jun 10, 2025 at 8:38 AM Philippe Altherr
<philippe.altherr@xxxxxxxxx> wrote:
>>
>> } else /* should this be in unsetparam_pm()? */
>
> I was expecting to find code that clears flags like PM_INTEGER in either bin_unset or in unsetparam_pm but I don't see anything like that. So it's a bit of a mystery to me how and where these flags get cleared and why only PM_NAMEREF needs to be explicitly cleared in bin_unset (or unsetparam_pm).
The flags are assigned at the end of createparam(), overwriting
whatever the old flags were. PM_NAMEREF is checked too early for
that, to cause the assignment to go through to the referent instead.
So that has to be cleared before we reach createparam().
For top-level parameters, this doesn't apply, because unsetparam_pm()
discards them entirely from the parameter table, but it can't do that
for locallevel > 0.
> For code with no errors, clearing PM_NAMEREF in bin_unset seems good enough but there are all these places that check for errors and then sometimes unset a parameter
That's likely to be a tricky one. An implicit reversal of an
assignment rather than an explicit unset -n might not always be
expected to undo the declaration.