[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Careful with dem hashes...

From: Jim Blandy <jimb_at_savonarola.red-bean.com>
Date: 2000-10-22 14:53:46 CEST

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

This is an archived mail posted to the Subversion Dev mailing list.