Re: [PATCH 03/11] hashmap_entry_init takes "struct hashmap_entry *"

From: Eric Wong <e@80x24.org>
Date: Aug 30, 2019, 19:48 UTC
Message-ID: <20190830194855.45jwupvp5uqcg46y@dcvr>
In-Reply-To: <nycvar.QRO.7.76.6.1908281655190.46@tvgsbejvaqbjf.bet>

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Show 19 quoted lines

> Hi Stolee,
> 
> On Tue, 27 Aug 2019, Derrick Stolee wrote:
> 
> > On 8/25/2019 10:43 PM, Eric Wong wrote:
> > > C compilers do type checking to make life easier for us.  So
> > > rely on that and update all hashmap_entry_init callers to take
> > > "struct hashmap_entry *" to avoid future bugs while improving
> > > safety and readability.
> >
> > Overall I like this change. I'll need to keep it in mind with my
> > sparse-checkout work that is adding more hashmap types.
> >
> > One _might_ think that this change is relaxing the condition on
> > where the hashmap_entry appears within the super-struct, but
> > the hashmap internals will still use void* and perform a cast
> > to hashmap_entry for hash comparisons.
> 
> I thought precisely the same.

Yes, that's the goal I'm working towards as mentioned in patches 10 and 11 :)

> Maybe we can get a Coccinelle rule that verifies that `struct
> hashmap_entryh` fields are always the first ones?

At this point, why? Given the goal is to remove that requirement entirely.