| Message ID | 20241118095507.GB3992317@coredump.intra.peff.net (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 2911f9ed1eccf92c4a98c50c3a88abb2c03a8126 |
| Headers | show |
| Series | -Wunterminated-string-initialization warning + cleanups | expand |
diff --git a/object-file.c b/object-file.c index 8101585616..19fc4afa43 100644 --- a/object-file.c +++ b/object-file.c @@ -326,9 +326,7 @@ static struct cached_object { static int cached_object_nr, cached_object_alloc; static struct cached_object empty_tree = { - .oid = { - .hash = EMPTY_TREE_SHA1_BIN_LITERAL, - }, + /* no oid needed; we'll look it up manually based on the_hash_algo */ .type = OBJ_TREE, .buf = "", };
We treat the empty tree specially, providing an in-memory "cached" copy, which allows you to diff against it even if the object doesn't exist in the repository. This is implemented as part of the larger cached_object subsystem, but we use a stand-alone empty_tree struct. We initialize the oid of that struct using EMPTY_TREE_SHA1_BIN_LITERAL. At first glance, that seems like a bug; how could this ever work for sha256 repositories? The answer is that we never look at the oid field! The oid field is used to look up entries added by pretend_object_file() to the cached_objects array. But for our stand-alone entry, we look for it independently using the_hash_algo->empty_tree, which will point to the correct algo struct for the repository. This happened in 62ba93eaa9 (sha1_file: convert cached object code to struct object_id, 2018-05-02), which even mentions that this field is never used. Let's reduce confusion for anybody reading this code by replacing the sha1 initializer with a comment. The resulting field will be all-zeroes, so any violation of our assumption that the oid field is not used will break equally for sha1 and sha256. Signed-off-by: Jeff King <peff@peff.net> --- object-file.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)