Colon-array variables can crash "sh" emulation

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Apr 14,  7:39pm, Anthony Fletcher wrote:
} 
} Playing further I provoked a segmentation fault! This dies:
}
}    ARGV0=sh zsh -c 'typeset -U path PATH'

Well, well, well.

The special_params array in Src/params.c is divided into two sections,
parameters available in all emulations and those available only in zsh
emulation.

Trouble is the parameters in the first group include numerous colon-array
scalars that are potentially tied to true-arrays from the second group.

This normally doesn't cause any issues, because the parameters in the
second group are initialized only in the appropriate emulation.

BUT -- the parameters in the first group will still try to read values
from the linked parameters in the second group if the attributes of the
first parameter are changed, as by "typeset -U".  Again this is usually
not a problem because the linked parameters are still not set.

However, if the linked parameter has been declared scalar, bin_typeset
will attempt to manipulate it as an array, and wallabies go roaming the
outback, as one of PWS's comments puts it.

This will happen with any pair of variables: path/PATH, watch/WATCH, etc.

However, I'm not sure of the best way to approach fixing this.  My first
thought was that the linkage should be broken during createparamtable(),
but that turns out to be rather ugly to do.

Here's what valgrind has to say:

==16106== Invalid read of size 1
==16106==    at 0x808DCE8: hasher (hashtable.c:85)
==16106==    by 0x808E0BF: gethashnode2 (hashtable.c:255)
==16106==    by 0x80C115F: arrayuniq (params.c:4001)
==16106==    by 0x80C123B: uniqarray (params.c:4031)
==16106==    by 0x80646F7: typeset_single (builtin.c:2201)
==16106==    by 0x806753A: bin_typeset (builtin.c:2893)
==16106==    by 0x805F232: execbuiltin (builtin.c:481)
==16106==    by 0x808066F: execcmd_exec (exec.c:3879)
==16106==    by 0x807AFC3: execpline2 (exec.c:1872)
==16106==    by 0x8079E36: execpline (exec.c:1602)
==16106==    by 0x807945B: execlist (exec.c:1360)
==16106==    by 0x8078C69: execode (exec.c:1141)
==16106==  Address 0x6C616300 is not stack'd, malloc'd or (recently) free'd

Any suggestions?