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.
