[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: another hash cleanup

From: Jim Meyering
Subject: Re: another hash cleanup
Date: Fri, 19 Jun 2009 14:02:01 +0200

Eric Blake wrote:

> According to Jim Meyering on 6/19/2009 1:19 AM:
>> However, I have a slight preference for this, since it leaves us
>> with less duplication of implementation-specific details:
>>   if (new_table->n_buckets == table->n_buckets)
>>     {
>>       hash_free (new_table);
>>       return true;
>>     }
>> It's on a cold code path, so the small amount of extra work isn't an issue.
>> Also, by using hash_free, we avoid a leak in the USE_OBSTACK code.
> Good catch (although the bit about USE_OBSTACK may be obsolete if I can
> get my alternate overflow management patch rebased on to the current state
> of the tree).
> But, come to think of it, why are we even malloc'ing the new_table at all
> in this code path?  Maybe the better technical approach would be factoring
> out the table size computation from hash_initialize, and have both
> hash_initialize and hash_rehash first compute the needed size and later do
> the malloc, so that hash_rehash doesn't even malloc in the first place if
> the size computation shows it isn't necessary.

Yes, I think that would be better still.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]