[PATCH v4] Replace memcpy with hashcpy when dealing hash copy globally

[PATCH v4] Replace memcpy with hashcpy when dealing hash copy globally

[Sun He]

hashcpy() can keep the abstraction of "object name" behind it.
Use it instead of memcpy() with hard-coded 20-byte length when
moving object names between pieces of memory.
We can benefit from it, when we switch to another hash algorithm,
eg. MD5, by just fixing the hashcpy().

Leave ppc/sha1.c as it is, because the function is about the
SHA-1 hash algorithm whose output is and will always be 20-byte.

Helped-by: Michael Haggerty <mhagger@alum.mit.edu>
Helped-by: Duy Nguyen <pclouds@gmail.com>
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Sun He <sunheehnus@gmail.com>
---
PATCH v4 changed the reason why should take this patch as tutored by
Junio C Hamano.
 Thanks to Junio C Hamano

PATCH v3 delete the one-space indentation on each line of commit message
as is suggested by Eric Sunshine.
 Thanks to Eric Sunshine.

PATCH v2 leave ppc/sha1.c alone.

The general rule is if cache.h or git-compat-util.h is included,
it is the first #include, and system includes will be always in
git-compat-tuil.h.
       				via Duy Nguyen

The change in PATCH v1 is not proper because I placed cache.h
in the end.
And adding it to the head is not a good way to achieve the goal,
as is said above "---".
 Thanks to Duy Nguyen.

Find the potential places with memcpy by the bash command:
 $ git grep 'memcpy.*20'
 Thanks to Junio C Hamano

 bundle.c            | 2 +-
 grep.c              | 2 +-
 pack-bitmap-write.c | 2 +-
 reflog-walk.c       | 4 ++--
 refs.c              | 2 +-
 5 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/bundle.c b/bundle.c
index e99065c..7809fbb 100644
--- a/bundle.c
+++ b/bundle.c
@@ -19,7 +19,7 @@ static void add_to_ref_list(const unsigned char *sha1, const char *name,
 		list->list = xrealloc(list->list,
 				list->alloc * sizeof(list->list[0]));
 	}
-	memcpy(list->list[list->nr].sha1, sha1, 20);
+	hashcpy(list->list[list->nr].sha1, sha1);
 	list->list[list->nr].name = xstrdup(name);
 	list->nr++;
 }
diff --git a/grep.c b/grep.c
index c668034..f5101f7 100644
--- a/grep.c
+++ b/grep.c
@@ -1650,7 +1650,7 @@ void grep_source_init(struct grep_source *gs, enum grep_source_type type,
 		break;
 	case GREP_SOURCE_SHA1:
 		gs->identifier = xmalloc(20);
-		memcpy(gs->identifier, identifier, 20);
+		hashcpy(gs->identifier, identifier);
 		break;
 	case GREP_SOURCE_BUF:
 		gs->identifier = NULL;
diff --git a/pack-bitmap-write.c b/pack-bitmap-write.c
index 1218bef..5f1791a 100644
--- a/pack-bitmap-write.c
+++ b/pack-bitmap-write.c
@@ -530,7 +530,7 @@ void bitmap_writer_finish(struct pack_idx_entry **index,
 	header.version = htons(default_version);
 	header.options = htons(flags | options);
 	header.entry_count = htonl(writer.selected_nr);
-	memcpy(header.checksum, writer.pack_checksum, 20);
+	hashcpy(header.checksum, writer.pack_checksum);
 
 	sha1write(f, &header, sizeof(header));
 	dump_bitmap(f, writer.commits);
diff --git a/reflog-walk.c b/reflog-walk.c
index b2fbdb2..d490f7d 100644
--- a/reflog-walk.c
+++ b/reflog-walk.c
@@ -32,8 +32,8 @@ static int read_one_reflog(unsigned char *osha1, unsigned char *nsha1,
 			sizeof(struct reflog_info));
 	}
 	item = array->items + array->nr;
-	memcpy(item->osha1, osha1, 20);
-	memcpy(item->nsha1, nsha1, 20);
+	hashcpy(item->osha1, osha1);
+	hashcpy(item->nsha1, nsha1);
 	item->email = xstrdup(email);
 	item->timestamp = timestamp;
 	item->tz = tz;
diff --git a/refs.c b/refs.c
index 89228e2..f90b7ea 100644
--- a/refs.c
+++ b/refs.c
@@ -1222,7 +1222,7 @@ static int resolve_gitlink_packed_ref(struct ref_cache *refs,
 	if (ref == NULL)
 		return -1;
 
-	memcpy(sha1, ref->u.value.sha1, 20);
+	hashcpy(sha1, ref->u.value.sha1);
 	return 0;
 }
 
-- 
1.9.0.138.g2de3478.dirty

Re: [PATCH v4] Replace memcpy with hashcpy when dealing hash copy globally

[Junio C Hamano]

Sun He <sunheehnus@gmail.com> writes:

> hashcpy() can keep the abstraction of "object name" behind it.

Do we really want to change the phrasing you took the above from to
say "*can* keep"?

Providing the "object name" abstraction is the whole point of the
function, so of course it can keep it, but that goes without
saying---it was the sole reason why it was invented in the first
place.

> Use it instead of memcpy() with hard-coded 20-byte length when
> moving object names between pieces of memory.
> We can benefit from it, when we switch to another hash algorithm,
> eg. MD5, by just fixing the hashcpy().

"fix" can be used in two scenarios, I think.  Something is broken
and you fix it, or something keeps changing and you force it not to
change.  I do not think either applies to hashcpy().  Perhaps
"updating", if we really wanted to say it, but because this change
is not about preparing us to any planned switch of hash function,
I'd suggest dropping those two lines starting from "We can benefit
from...".

> Leave ppc/sha1.c as it is, because the function is about the
> SHA-1 hash algorithm whose output is and will always be 20-byte.

Correct.