summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJeff King <peff@peff.net>2019-09-05 22:52:49 (GMT)
committerJunio C Hamano <gitster@pobox.com>2019-09-06 18:03:39 (GMT)
commit7140414d8bd7ed1a05b83bc34d0d0e76ef8b12bd (patch)
tree2ac0d877d891afb5a8b6a82b04207b66cb489c98
parentf1cbd033e201a18c7175bc6509b48d6243e79739 (diff)
downloadgit-7140414d8bd7ed1a05b83bc34d0d0e76ef8b12bd.zip
git-7140414d8bd7ed1a05b83bc34d0d0e76ef8b12bd.tar.gz
git-7140414d8bd7ed1a05b83bc34d0d0e76ef8b12bd.tar.bz2
bulk-checkin: zero-initialize hashfile_checkpoint
We declare a "struct hashfile_checkpoint" but only sometimes actually call hashfile_checkpoint() on it. That makes it not immediately obvious that it's valid when we later access its members. In fact, the code is fine: we fill it in unconditionally in the while(1) loop as long as "idx" is non-NULL. And then if "idx" is NULL, we exit early from the function (because we're just computing the hash, not actually writing), before we look at the struct. However, this does seem to confuse gcc 9.2.1's -Wmaybe-uninitialized when compiled with "-flto -O2" (probably because with LTO it can now realize that our call to hashfile_truncate() does not set the members either). Let's zero-initialize the struct to tell the compiler, as well as any readers of the code, that all is well. Reported-by: Stephan Beyer <s-beyer@gmx.net> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
-rw-r--r--bulk-checkin.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/bulk-checkin.c b/bulk-checkin.c
index 39ee7d6..583aacb 100644
--- a/bulk-checkin.c
+++ b/bulk-checkin.c
@@ -197,7 +197,7 @@ static int deflate_to_pack(struct bulk_checkin_state *state,
git_hash_ctx ctx;
unsigned char obuf[16384];
unsigned header_len;
- struct hashfile_checkpoint checkpoint;
+ struct hashfile_checkpoint checkpoint = {0};
struct pack_idx_entry *idx = NULL;
seekback = lseek(fd, 0, SEEK_CUR);