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

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

 



On 9/23/2019 9:03 PM, Eric Wong wrote:
> 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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux