git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Stefan Beller <sbeller@google.com>
Cc: git@vger.kernel.org, jrnieder@gmail.com, git@jeffhostetler.com
Subject: Re: [PATCHv2 1/2] hashmap.h: compare function has access to a data field
Date: Fri, 30 Jun 2017 10:39:45 -0700	[thread overview]
Message-ID: <xmqqh8yxs7by.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <20170629235336.28460-2-sbeller@google.com> (Stefan Beller's message of "Thu, 29 Jun 2017 16:53:35 -0700")

Stefan Beller <sbeller@google.com> writes:

> diff --git a/patch-ids.c b/patch-ids.c
> index 9c0ab9e67a..b9b2ebbad0 100644
> --- a/patch-ids.c
> +++ b/patch-ids.c
> @@ -37,6 +37,7 @@ int commit_patch_id(struct commit *commit, struct diff_options *options,
>   */
>  static int patch_id_cmp(struct patch_id *a,
>  			struct patch_id *b,
> +			const void *unused_keydata,
>  			struct diff_options *opt)
>  {
>  	if (is_null_oid(&a->patch_id) &&
> @@ -57,7 +58,8 @@ int init_patch_ids(struct patch_ids *ids)
>  	ids->diffopts.detect_rename = 0;
>  	DIFF_OPT_SET(&ids->diffopts, RECURSIVE);
>  	diff_setup_done(&ids->diffopts);
> -	hashmap_init(&ids->patches, (hashmap_cmp_fn)patch_id_cmp, 256);
> +	hashmap_init(&ids->patches, (hashmap_cmp_fn)patch_id_cmp,
> +		     &ids->diffopts, 256);
>  	return 0;
>  }
>  
> @@ -93,7 +95,7 @@ struct patch_id *has_commit_patch_id(struct commit *commit,
>  	if (init_patch_id_entry(&patch, commit, ids))
>  		return NULL;
>  
> -	return hashmap_get(&ids->patches, &patch, &ids->diffopts);
> +	return hashmap_get(&ids->patches, &patch, NULL);
>  }

This actually makes me wonder if we can demonstrate an existing
breakage in tests.  The old code used to pass NULL to the diffopts,
causing it to be passed down through commit_patch_id() function down
to diff_tree_oid() or diff_root_tree_oid().  When the codepath
triggers the issue that Peff warned about in his old article (was it
about rehashing or something?) that makes two entries compared
(i.e. not using keydata, because we are not comparing an existing
entry with a key and data only to see if that already exists in the
hashmap), wouldn't that cause ll_diff_tree_oid() that is called from
diff_tree_oid() to dereference NULL?

Thanks.

  parent reply	other threads:[~2017-06-30 17:39 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-29  1:13 [PATCH 0/2] Introduce data field in hashmap and migrate docs to header Stefan Beller
2017-06-29  1:13 ` [PATCH 1/2] hashmap.h: compare function has access to a data field Stefan Beller
2017-06-29 18:06   ` Junio C Hamano
2017-06-29 18:11     ` Junio C Hamano
2017-06-29 18:20       ` Stefan Beller
2017-06-30 17:26         ` Junio C Hamano
2017-06-29  1:13 ` [PATCH 2/2] hashmap: migrate documentation from Documentation/technical into header Stefan Beller
2017-06-29 13:25   ` Jeff Hostetler
2017-06-29 21:18   ` Jonathan Nieder
2017-06-29 23:41     ` Stefan Beller
2017-06-29 23:53 ` [PATCHv2 0/2] Introduce data field in hashmap and migrate docs to header Stefan Beller
2017-06-29 23:53   ` [PATCHv2 1/2] hashmap.h: compare function has access to a data field Stefan Beller
2017-06-30 17:34     ` Junio C Hamano
2017-06-30 17:41       ` Stefan Beller
2017-06-30 18:47         ` Junio C Hamano
2017-06-30 18:57           ` Stefan Beller
2017-06-30 17:39     ` Junio C Hamano [this message]
2017-06-30 18:00       ` Stefan Beller
2017-06-30 18:40         ` Junio C Hamano
2017-06-29 23:53   ` [PATCHv2 2/2] hashmap: migrate documentation from Documentation/technical into header Stefan Beller
2017-06-30 19:14   ` [PATCHv3 0/3] Introduce data field in hashmap and migrate docs to header Stefan Beller
2017-06-30 19:14     ` [PATCHv3 1/3] hashmap.h: compare function has access to a data field Stefan Beller
2017-06-30 19:14     ` [PATCHv3 2/3] patch-ids.c: use hashmap correctly Stefan Beller
2017-06-30 19:50       ` Junio C Hamano
2017-07-05  9:00       ` Jeff King
2017-06-30 19:14     ` [PATCHv3 3/3] hashmap: migrate documentation from Documentation/technical into header Stefan Beller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqh8yxs7by.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@jeffhostetler.com \
    --cc=git@vger.kernel.org \
    --cc=jrnieder@gmail.com \
    --cc=sbeller@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).