Yeah, I noticed that and made appropriate accomodations. It makes
some sense in retrospect (what if your keys are *really* *big* --- do
you want your hash table copying them?), but I was surprised.
This behavior definitely needs a mention in apr_hash.h.
Ben Collins-Sussman <sussman@newton.collab.net> writes:
> Karl and I had a realization this morning that when you do
>
> apr_hash_set (hash, key, keylen, val);
>
> The keys are *not* copied into the hash's internal pool.
>
> Now, we've all been paranoid about duplicating value-objects before
> storing them, but I wonder if folks have been applying this same
> mentality to the key objects.
>
> We need to be careful that the stored key isn't ever allocated in a
> subpool that lives *below* the pool that the hash is in.
>
> I've already searched through most of our codebase, but I don't know
> enough to analyze two specific spots. Greg H? Jimb? You guys might
> want to double-check.
>
> (grepping for `apr_hash_set':)
>
>
> In ./libsvn_delta/xml_output.c, line 281:
> apr_hash_set (att, "ancestor", strlen("ancestor"), ancestor_path);
> In ./libsvn_delta/xml_output.c, line 283:
> apr_hash_set (att, "ver", strlen("ver"), svn_string_create (buf, pool));
> In ./libsvn_fs/node.c, line 263:
> apr_hash_set (cache, id, id_size, 0);
> In ./libsvn_fs/node.c, line 292:
> apr_hash_set (fs->node_cache, id, id_size, node);
> In ./libsvn_fs/proplist.c, line 98:
> apr_hash_set (p->hash, name_copy, name->len, value_copy);
> In ./libsvn_fs/proplist.c, line 208:
> apr_hash_set (copy, name_copy, name_len, value_copy);
> In ./libsvn_fs/txn.c, line 328:
> apr_hash_set (fs->open_txns, txn->id, 0, txn);
Received on Sat Oct 21 14:36:12 2006