git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Michael Haggerty <mhagger@alum.mit.edu>
Cc: Johan Herland <johan@herland.net>,
	Johannes Schindelin <johannes.schindelin@gmx.de>,
	git@vger.kernel.org
Subject: Re: [PATCH 02/12] load_subtree(): remove unnecessary conditional
Date: Sat, 26 Aug 2017 09:38:49 -0700	[thread overview]
Message-ID: <xmqqh8wuqo6e.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <c21bedbee9487792f4a336a417aa9874578aaac2.1503734566.git.mhagger@alum.mit.edu> (Michael Haggerty's message of "Sat, 26 Aug 2017 10:28:02 +0200")

Michael Haggerty <mhagger@alum.mit.edu> writes:

> At this point in the code, len is *always* <= 20.

This is the kind of log message that makes me unconfortable, as it
lacks "because", and the readers would need to find out themselves
by following the same codepath the patch author already followed.

There is an assert earlier before the control gets in this loop

	prefix_len = subtree->key_oid.hash[KEY_INDEX];
	assert(prefix_len * 2 >= n);
	memcpy(object_oid.hash, subtree->key_oid.hash, prefix_len);

that tries to ensure there is sufficient number of prefix defined in
that key, and the codeflow may ensure that prefix_len is both an
even number and shorter than 20 (the correctness of the code depends
on these, it seems, and if for some reason prefix_len is much
larger, calls to get_oid_hex_segment() will overflow the oid.hash[]
array without checking).  I'd at least feel safer to have an assert
next to the existing one that catches a bug to throw a randomly
large value into subtree->key_oid.hash[KEY_INDEX].  Then we can
safely say "at this point in the code, len is always <= 20", as that
assert will makes it obvious without looking at anything other than
this code and get_oid_hex_segment() implementaiton (combined with
the fact that this function is the only one that coerces len and
puts it into ->key_oid.hash[KEY_INDEX], but that is a weak assurance
as we cannot tell where "subtree" came from---it may have full
20-byte oid in its key_oid field---without following the callchain a
lot more widely).

> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
> ---
>  notes.c | 35 +++++++++++++++++------------------
>  1 file changed, 17 insertions(+), 18 deletions(-)
>
> diff --git a/notes.c b/notes.c
> index 00630a9396..f7ce64ff48 100644
> --- a/notes.c
> +++ b/notes.c
> @@ -446,25 +446,24 @@ static void load_subtree(struct notes_tree *t, struct leaf_node *subtree,
>  		 * If object SHA1 is incomplete (len < 20), and current
>  		 * component consists of 2 hex chars, assume note subtree
>  		 */
> -		if (len <= GIT_SHA1_RAWSZ) {
> -			type = PTR_TYPE_NOTE;
> -			l = (struct leaf_node *)
> -				xcalloc(1, sizeof(struct leaf_node));
> -			oidcpy(&l->key_oid, &object_oid);
> -			oidcpy(&l->val_oid, entry.oid);
> -			if (len < GIT_SHA1_RAWSZ) {
> -				if (!S_ISDIR(entry.mode) || path_len != 2)
> -					goto handle_non_note; /* not subtree */
> -				l->key_oid.hash[KEY_INDEX] = (unsigned char) len;
> -				type = PTR_TYPE_SUBTREE;
> -			}
> -			if (note_tree_insert(t, node, n, l, type,
> -					     combine_notes_concatenate))
> -				die("Failed to load %s %s into notes tree "
> -				    "from %s",
> -				    type == PTR_TYPE_NOTE ? "note" : "subtree",
> -				    oid_to_hex(&l->key_oid), t->ref);
> +		type = PTR_TYPE_NOTE;
> +		l = (struct leaf_node *)
> +			xcalloc(1, sizeof(struct leaf_node));
> +		oidcpy(&l->key_oid, &object_oid);
> +		oidcpy(&l->val_oid, entry.oid);
> +		if (len < GIT_SHA1_RAWSZ) {
> +			if (!S_ISDIR(entry.mode) || path_len != 2)
> +				goto handle_non_note; /* not subtree */
> +			l->key_oid.hash[KEY_INDEX] = (unsigned char) len;
> +			type = PTR_TYPE_SUBTREE;
>  		}
> +		if (note_tree_insert(t, node, n, l, type,
> +				     combine_notes_concatenate))
> +			die("Failed to load %s %s into notes tree "
> +			    "from %s",
> +			    type == PTR_TYPE_NOTE ? "note" : "subtree",
> +			    oid_to_hex(&l->key_oid), t->ref);
> +
>  		continue;
>  
>  handle_non_note:

  reply	other threads:[~2017-08-26 16:38 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-26  8:28 [PATCH 00/12] Clean up notes-related code around `load_subtree()` Michael Haggerty
2017-08-26  8:28 ` [PATCH 01/12] notes: make GET_NIBBLE macro more robust Michael Haggerty
2017-08-26  8:28 ` [PATCH 02/12] load_subtree(): remove unnecessary conditional Michael Haggerty
2017-08-26 16:38   ` Junio C Hamano [this message]
2017-08-27  6:37     ` Michael Haggerty
2017-08-28  6:55       ` Michael Haggerty
2017-09-01 21:53         ` Junio C Hamano
2017-08-26  8:28 ` [PATCH 03/12] load_subtree(): reduce the scope of some local variables Michael Haggerty
2017-08-26  8:28 ` [PATCH 04/12] load_subtree(): fix incorrect comment Michael Haggerty
2017-08-26  8:28 ` [PATCH 05/12] load_subtree(): separate logic for internal vs. terminal entries Michael Haggerty
2017-08-26  8:28 ` [PATCH 06/12] load_subtree(): check earlier whether an internal node is a tree entry Michael Haggerty
2017-08-26  8:28 ` [PATCH 07/12] load_subtree(): only consider blobs to be potential notes Michael Haggerty
2017-08-26  8:28 ` [PATCH 08/12] get_oid_hex_segment(): return 0 on success Michael Haggerty
2017-08-26  8:28 ` [PATCH 09/12] load_subtree(): combine some common code Michael Haggerty
2017-08-26  8:28 ` [PATCH 10/12] get_oid_hex_segment(): don't pad the rest of `oid` Michael Haggerty
2017-08-26  8:28 ` [PATCH 11/12] hex_to_bytes(): simpler replacement for `get_oid_hex_segment()` Michael Haggerty
2017-08-26  8:28 ` [PATCH 12/12] load_subtree(): declare some variables to be `size_t` Michael Haggerty
2017-08-26 23:36 ` [PATCH 00/12] Clean up notes-related code around `load_subtree()` Johan Herland
2017-09-09 10:31 ` Jeff King
2017-09-10  4:45   ` Michael Haggerty
2017-09-10  7:39     ` Jeff King
2017-09-12  6:47       ` Michael Haggerty
2017-09-12 11:55       ` Lars Schneider

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=xmqqh8wuqo6e.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=johan@herland.net \
    --cc=johannes.schindelin@gmx.de \
    --cc=mhagger@alum.mit.edu \
    /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).