Re: [PATCH] Use realparamtab and don't dereference special parameters in zle code

>
> In makecompparams(), is it really always guaranteed that paramtab ==
> realparamtab on entry to the function?  (See hardwired reset at the
> end.)  The save/restore with "tht" seems like otherwise-harmless
> defensive programming.


The function makecompparams creates Param instances for the
parameters declared in comprparams
<https://github.com/zsh-users/zsh/blob/ebccc0744000d8f92de66a60258c8834f52151ea/Src/Zle/complete.c#L1262>.
I'm pretty sure that these are meant to always be defined in the real
parameter table. If that wasn't the case, it would add an array value
<https://github.com/zsh-users/zsh/blob/ebccc0744000d8f92de66a60258c8834f52151ea/Src/Zle/complete.c#L1263>
to a hashtable and this line
<https://github.com/zsh-users/zsh/blob/ebccc0744000d8f92de66a60258c8834f52151ea/Src/Zle/complete.c#L1357>
would
add a hashtable value to that same hashtable. The Zsh language only
supports string values in hashtables. Technically it's possible to create
other types of values in hashtables but I wouldn't bet that array values
and especially hashtable values work. Interestingly integer values must
work because this line
<https://github.com/zsh-users/zsh/blob/ebccc0744000d8f92de66a60258c8834f52151ea/Src/Zle/complete.c#L1365>
adds Param instances to the compstate hashtable
<https://github.com/zsh-users/zsh/blob/ebccc0744000d8f92de66a60258c8834f52151ea/Src/Zle/complete.c#L1355>
for the parameters declared in compkparams
<https://github.com/zsh-users/zsh/blob/ebccc0744000d8f92de66a60258c8834f52151ea/Src/Zle/complete.c#L1275>,
which includes multiple integer parameters.

I added a DPUTS at the beginning of makecompparams to check whether paramtab
== realparamtab and that was indeed true in all tests and the few manual
interactions I tried.


> Why remove PM_NAMEREF in makezleparams()?  Just because right now
> there are no ZLE parameters that are named references doesn't mean
> there might not be at some point?
>
>   switch(PM_TYPE(zp->type)) {
>      case PM_SCALAR:
> -    case PM_NAMEREF:
>           pm->gsu.s = zp->gsu;
>   break;
>

The two PM_NAMEREF that I'm removing were added in 53776: Add PM_NAMEREF to
PM_TYPE, reject array initializers for namerefs
<https://github.com/zsh-users/zsh/commit/09e1b5631dfe367aa8e44acf28bc8581a47a5d54>.
Before that patch, PM_TYPE() returned PM_SCALAR for both string values and
named references. Thus, the code above (with no case PM_NAMEREF)
implicitly handled named references. In the patch, I mechanically added the
case PM_NAMEREF to ensure that the code keeps behaving the same. Since then
the code explicitly "supports" named references but now, after having a
closer look at the code, I'm pretty sure that the original implicit support
was accidental. For that reason I think that it's better to remove the case
PM_NAMEREF. If someone ever wants to add a named reference to comprparams
<https://github.com/zsh-users/zsh/blob/ebccc0744000d8f92de66a60258c8834f52151ea/Src/Zle/complete.c#L1262>
, compkparams
<https://github.com/zsh-users/zsh/blob/ebccc0744000d8f92de66a60258c8834f52151ea/Src/Zle/complete.c#L1275>,
or zleparams
<https://github.com/zsh-users/zsh/blob/ebccc0744000d8f92de66a60258c8834f52151ea/Src/Zle/zle_params.c#L141>,
they can figure out what's actually needed to properly support named
references in addcompparams
<https://github.com/zsh-users/zsh/blob/ebccc0744000d8f92de66a60258c8834f52151ea/Src/Zle/complete.c#L1311>
 or makezleparams
<https://github.com/zsh-users/zsh/blob/ebccc0744000d8f92de66a60258c8834f52151ea/Src/Zle/zle_params.c#L194>
.

Philippe