Re: Memory leak when working with undefined associative array keys & problems with unset

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Sep 16,  8:57pm, Anssi Palin wrote:
}
} Zsh appears to permanently allocate some memory when just checking
} if a key is defined in an associative array.

Hmm.

This has to do with order of operations.  In order to test whether a[0]
is (not) set, the calling code needs a "struct pm" object for which it
can attempt to retrieve a value and/or check the PM_UNSET flag.  For a
hash-typed parameter, there's nowhere to temporarily store such an
object except in the hashtable itself.  The same level of evaluation
that tests ${+...} also handles ${...::=...} which also needs that
struct to store into, so we can't NOT allocate it, and because all
parameter ops are by value rather than by reference we can't wait until
after we've assigned to it to add it to the hash (the knowledge that
"a[0]" is part of the hash "a" or even that the key is "0", is lost
by the time we're ready to do the assignment -- we have only a handle
to the object that resides at $a[0]).

The naughty bit is approximately here:

#0  getparamnode (ht=0x92c3898, nam=0xb7cb7818 "0")
    at ../../zsh-5.0/Src/params.c:496
#1  0x080baa56 in createparam (name=0xb7cb7818 "0", flags=570425344)
    at ../../zsh-5.0/Src/params.c:963
#2  0x080bb869 in getarg (str=0xbfee7eb8, inv=0xbfee7ebc, v=0xbfee8130, a2=0, 
    w=0xbfee7ea8, prevcharlen=0xbfee7e9c, nextcharlen=0xbfee7e98)
    at ../../zsh-5.0/Src/params.c:1417
#3  0x080bcf10 in getindex (pptr=0xbfee7f14, v=0xbfee8130, flags=0)
    at ../../zsh-5.0/Src/params.c:1851
#4  0x080bd548 in fetchvalue (v=0xbfee8130, pptr=0xbfee8194, bracks=1, flags=0)
    at ../../zsh-5.0/Src/params.c:2069
#5  0x080e0193 in paramsubst (l=0xb7cb77a8, n=0xb7cb77c0, str=0xbfee8208, 
    qt=0, pf_flags=0, ret_flags=0xbfee836c) at ../../zsh-5.0/Src/subst.c:2418

I think paramsubst() "knows" that it only wants to check set/unset, but
that can't be passed down through fetchvalue() so getarg() doesn't know
that it shouldn't create the hashtable element.

} The second issue I have pertains to special characters in associative
} array keys when unsetting them individually:
}
} $ key='hello * [ world'
} $ typeset -A a=("$key" val)
} $ unset "a[$key]"
} unset: a[hello * [ world]: invalid parameter name

Hmm, when examining ${a[$key]} we enter parse_subscript() with $key
tokenized, but there's no way to get the tokenized string to reach
the same point in the unset builtin (it's either already expanded,
or not tokenized).  Also ${a[$key]} passes sub=0 to parse_subscript()
whereas "unset" always passes sub=1, but I'm uncertain how that may
be relevant.

This may argue for making unset a keyword ala typeset, but perhaps
someone else has a clever approach.