Re: [PATCH 1/5] refs: store submodule ref stores in a hashmap

From: Jeff King <peff@peff.net>
Date: Feb 10, 2017, 04:04 UTC
Message-ID: <20170210040400.kf6hurtcblnoxdqi@sigill.intra.peff.net>
In-Reply-To: <xmqqh943p0hv.fsf@gitster.mtv.corp.google.com>

On Thu, Feb 09, 2017 at 12:34:04PM -0800, Junio C Hamano wrote:

Show 8 quoted lines

> > +static struct submodule_hash_entry *alloc_submodule_hash_entry(
> > +		const char *submodule, struct ref_store *refs)
> > +{
> > +	size_t len = strlen(submodule);
> > +	struct submodule_hash_entry *entry = malloc(sizeof(*entry) + len + 1);
> 
> I think this (and the later memcpy) is what FLEX_ALLOC_MEM() was
> invented for.

Yes, it was. Though since the length comes from a strlen() call, it can actually use the _STR variant, like:

  FLEX_ALLOC_STR(entry, submodule, submodule);

Besides being shorter, this does integer-overflow checks on the final length.

Show 17 quoted lines

> > @@ -1373,16 +1405,17 @@ void base_ref_store_init(struct ref_store *refs,
> >  			die("BUG: main_ref_store initialized twice");
> >  
> >  		refs->submodule = "";
> > -		refs->next = NULL;
> >  		main_ref_store = refs;
> >  	} else {
> > -		if (lookup_ref_store(submodule))
> > +		refs->submodule = xstrdup(submodule);
> > +
> > +		if (!submodule_ref_stores.tablesize)
> > +			hashmap_init(&submodule_ref_stores, submodule_hash_cmp, 20);
> 
> Makes me wonder what "20" stands for.  Perhaps the caller should be
> allowed to say "I do not quite care what initial size is" by passing
> 0 or some equally but more clealy meaningless value (which of course
> would be outside the scope of this series).

I think this is what "0" already does (grep for HASHMAP_INITIAL_SIZE). In fact, that constant is 64. The 20 we pass in goes through some magic load-factor computation and ends up as 25. That being smaller than the INITIAL_SIZE constant, I believe that we end up allocating 64 entries either way (that's just from reading the code, though; I didn't run it to double check).

-Peff