summaryrefslogtreecommitdiff
path: root/Documentation/git-hash-object.txt
diff options
context:
space:
mode:
authorLibravatar Jeff King <peff@peff.net>2019-09-05 18:52:49 -0400
committerLibravatar Junio C Hamano <gitster@pobox.com>2019-09-06 11:03:39 -0700
commit7140414d8bd7ed1a05b83bc34d0d0e76ef8b12bd (patch)
tree2ac0d877d891afb5a8b6a82b04207b66cb489c98 /Documentation/git-hash-object.txt
parentpack-objects: use object_id in packlist_alloc() (diff)
downloadtgif-7140414d8bd7ed1a05b83bc34d0d0e76ef8b12bd.tar.xz
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>
Diffstat (limited to 'Documentation/git-hash-object.txt')
0 files changed, 0 insertions, 0 deletions