threads / patch / 36073

v4Replace memcpy with hashcpy when dealing hash copy globally

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

## tl;dr

2 messages between Mar 6, 2014 and Mar 6, 2014. Diffs are folded; open one to read it.

replies: 1people: 2as markdown or json

Sun He· Mar 6, 2014, 09:11 UTC · lore

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(-)
Show changes to 5 files +6 −6

bundle.c, grep.c, pack-bitmap-write.c, reflog-walk.c, refs.c

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
Junio C Hamano· Mar 6, 2014, 19:32 UTC · re: Sun He · lore

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

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.

← back to recent threads