On Sat, 26 Feb 2000 18:19:03 EST, John Tobey wrote: >NOTE: This patch may be too unstable to apply so close to 5.6. All >tests pass, but I am not certain that the assumptions about op type in >Perl_ck_aassign are justified. Agreed. I haven't looked closely, but the ck_aassign() code appears to be not defensive enough. > I'd like to check my changes in >pp_aassign for memory leakage. I have actually changed the prototype >and semantics of a public avhv function, Perl_avhv_fetch_ent. (The >final argument seemed non-useful, was never used in the source, and >since the interface is 'experimental' and undocumented, I think it >better to change it now than to add a differently named function.) I don't think this change is advisable. Computing the hash value for a particular key is a linear time (O(n)) operation, while fetching the first hashref entry is constant time. So it makes more sense to let them supply a pre-computed value for the hash. More than simply making sense, the 'hash' argument is *required* for consistency when someone wants to use their own hashing algorithm for their hashes, but use Perl's internal hash table routines. This might make sense if you have a custom data set on which Perl's algorithm performs poorly (as it is known to on keys that are repeating sequences). This was the other particular intent in making all the *_ent() functions take a hash argument. Thanks. Sarathy gsar@ActiveState.com