Re: another hash cleanup

[Jim Meyering]

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.