summaryrefslogtreecommitdiff
path: root/builtin
diff options
context:
space:
mode:
authorJeff King <peff@peff.net>2017-05-19 12:52:25 (GMT)
committerJunio C Hamano <gitster@pobox.com>2017-05-24 01:59:27 (GMT)
commitd72cae12b9a7bba3a6626e0b5805955eafdefcc6 (patch)
treea1c37bf5761c0c114c0067ad6c01a77426d93207 /builtin
parentc0a487eafb63301004af424bf02b1951abdc4da7 (diff)
downloadgit-d72cae12b9a7bba3a6626e0b5805955eafdefcc6.zip
git-d72cae12b9a7bba3a6626e0b5805955eafdefcc6.tar.gz
git-d72cae12b9a7bba3a6626e0b5805955eafdefcc6.tar.bz2
get_sha1_with_context: always initialize oc->symlink_path
The get_sha1_with_context() function zeroes out the oc->symlink_path strbuf, but doesn't use strbuf_init() to set up the usual invariants (like pointing to the slopbuf). We don't actually write to the oc->symlink_path strbuf unless we call get_tree_entry_follow_symlinks(), and that function does initialize it. However, readers may still look at the zero'd strbuf. In practice this isn't a triggerable bug. The only caller that looks at it only does so when the mode we found is 0. This doesn't happen for non-tree-entries (where we return S_IFINVALID). A broken tree entry could have a mode of 0, but canon_mode() quietly rewrites that into S_IFGITLINK. So the "0" mode should only come up when we did indeed find a symlink. This is mostly just an accident of how the code happens to work, though. Let's future-proof ourselves to make sure the strbuf is properly initialized for all calls (it's only a few struct member assignments, not a heap allocation). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'builtin')
0 files changed, 0 insertions, 0 deletions