David Glasser wrote:
> On Wed, May 21, 2008 at 6:41 PM, John Peacock
> <john.peacock_at_havurah-software.org> wrote:
>
>> I'm trying to translate the Python SWIG bindings to Perl and I came across
>> this code:
>>
>> ...
>> hash = apr_hash_make(pool);
>> keys = PyDict_Keys(dict);
>> num_keys = PyList_Size(keys);
>> for (i = 0; i < num_keys; i++)
>> {
>> PyObject *key = PyList_GetItem(keys, i);
>> PyObject *value = PyDict_GetItem(dict, key);
>> const char *pathname = make_string_from_ob(key, pool);
>> apr_array_header_t *ranges = svn_swig_py_rangelist_to_array(value,
>> pool);
>>
>> if (! (pathname && ranges))
>> {
>> PyErr_SetString(PyExc_TypeError,
>> "dictionary keys aren't strings or values aren't
>> svn_merge_range_t *'s");
>> Py_DECREF(keys);
>> return NULL;
>> }
>> ...
>>
>> If the error path is followed, isn't that hash leaked, or does the pool
>> automatically get cleaned up somewhere else? I'm trying desperately not to
>> engage in cargo-cult programming.
>>
>
> While this may not be a good thing or worth continuing, failure to
> destroy/clear pools on error is pretty endemic in Subversion. I guess
> the assumption is that it's likely the program is about to destroy a
> top-level pool anyway, so who cares; it would be neat if there was a
> better idiom for dealing.
>
It's not obvious from the code snippet above that anyone forgot to
destroy a hash or clear a pool -- I don't see any pool creation there,
so obviously there should be no pool destruction either. And the only
way to destroy a hash is to clear its container pool, right?
So either this code snippet is not complete, or everything is as per spec.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-05-22 10:49:47 CEST