Derrick Stolee <sto...@gmail.com> writes: > On 10/15/2019 3:11 AM, Eric Wong wrote: >> Junio C Hamano <gits...@pobox.com> wrote: >>> Eric Wong <e...@80x24.org> writes: >>> >>>> I just took a brief look, but that appears to leak memory. >>>> >>>> "hashmap_free(var, 1)" should be replaced with >>>> "hashmap_free_entries(var, struct foo, member)" >>>> >>>> Only "hashmap_free(var, 0)" can become "hashmap_free(var)" >>> >>> I deliberately avoided merge-time band-aid fixups on this topic and >>> ew/hashmap exactly because I was sure that I'd introduce a similar >>> bugs by doing so myself. Using evil merges can be a great way to >>> help multiple topics polished independently at the same time, but >>> when overused, can hide this kind of gotchas quite easily. >>> >>> A reroll on top of ew/hashmap would be desirable, now that topic is >>> ready for 'master'. >> >> Just to be clear, that reroll should come from Stolee (+Cc-ed), right? >> I'll be around to help answer questions, but also pretty busy >> with other stuff and I think Stolee knows this API pretty well :> > > I'm working on the re-roll, yes. I was waiting for ew/hashmap to merge > with history that included ds/include-exclude. Now the current 'master' > has both, so I can rebase and check everything carefully. v4 should > have every commit compile with the new hashmap API.
Thanks, both.
