summaryrefslogtreecommitdiff
path: root/hex.c
diff options
context:
space:
mode:
authorbrian m. carlson <sandals@crustytoothpaste.net>2021-04-26 01:03:00 (GMT)
committerJunio C Hamano <gitster@pobox.com>2021-04-27 07:31:39 (GMT)
commitb8505ecbf2b1e4ef27b9597fd113cb1679792b29 (patch)
tree4394a10a7d4c08e781ff062fd876e876fda48d0e /hex.c
parent71b7672b674bc9a44fb41428804be428c2981046 (diff)
downloadgit-b8505ecbf2b1e4ef27b9597fd113cb1679792b29.zip
git-b8505ecbf2b1e4ef27b9597fd113cb1679792b29.tar.gz
git-b8505ecbf2b1e4ef27b9597fd113cb1679792b29.tar.bz2
hex: default to the_hash_algo on zero algorithm value
There are numerous places in the codebase where we assume we can initialize data by zeroing all its bytes. However, when we do that with a struct object_id, it leaves the structure with a zero value for the algorithm, which is invalid. We could forbid this pattern and require that all struct object_id instances be initialized using oidclr, but this seems burdensome and it's unnatural to most C programmers. Instead, if the algorithm is zero, assume we wanted to use the default hash algorithm instead. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'hex.c')
-rw-r--r--hex.c7
1 files changed, 7 insertions, 0 deletions
diff --git a/hex.c b/hex.c
index e7af18f..74d256f 100644
--- a/hex.c
+++ b/hex.c
@@ -124,6 +124,13 @@ char *hash_to_hex_algop_r(char *buffer, const unsigned char *hash,
char *buf = buffer;
int i;
+ /*
+ * Our struct object_id has been memset to 0, so default to printing
+ * using the default hash.
+ */
+ if (algop == &hash_algos[0])
+ algop = the_hash_algo;
+
for (i = 0; i < algop->rawsz; i++) {
unsigned int val = *hash++;
*buf++ = hex[val >> 4];