Re: [PATCH v2 00/19] hashmap bug/safety/ease-of-use fixes

From: Derrick Stolee <stolee@gmail.com>
Date: Sep 25, 2019, 13:30 UTC
Message-ID: <d16b22c9-c437-0947-fb5a-9421f987a1f1@gmail.com>
In-Reply-To: <20190924010324.22619-1-e@80x24.org>

On 9/23/2019 9:03 PM, Eric Wong wrote:

Show 11 quoted lines

> Patches 1-11 are largely unchanged from the original series with the
> exception of 2, which is new and posted at:
> 
> 	https://public-inbox.org/git/20190908074953.kux7zz4y7iolqko4@whir/
> 
> 12-17 take further steps to get us away from hashmap_entry being
> the first element, but they're also a bit ugly because __typeof__
> isn't portable
> 
> 18-19 finally brings me to the APIs I want to expose without
> relying on __typeof :)

I like this series a lot. The goal is very noble. As one who recently interacted with the hashmap API for the first time, I would have preferred working with the new API.

I do wonder about it conflicting with my sparse-checkout changes, which create a lot of new callers to the API. I suspect that your change will be easier to merge quickly and I will want to rebase on top. Perhaps Junio could chime in with his preferred integration plan?

As for review, I have mostly minor comments. There appears to be consistent whitespace issues in hashmap.c and hashmap.h, but maybe I'm reading them incorrectly.

Also, consider merging patches 10 & 11 as 11 seems to undo the work in patch 10.

Thanks, -Stolee