]> git.ipfire.org Git - thirdparty/git.git/commit
global: ensure that object IDs are always padded
authorPatrick Steinhardt <ps@pks.im>
Fri, 14 Jun 2024 06:49:59 +0000 (08:49 +0200)
committerJunio C Hamano <gitster@pobox.com>
Fri, 14 Jun 2024 17:26:32 +0000 (10:26 -0700)
commitc98d762ed96ba9beead28608b3c7d1e477a8fe3d
tree1f8ca665c28c7e3719f8e4ddc5a2ff5e4c18eb74
parent9da95bda74cf10e1475384a71fd20914c3b99784
global: ensure that object IDs are always padded

The `oidcmp()` and `oideq()` functions only compare the prefix length as
specified by the given hash algorithm. This mandates that the object IDs
have a valid hash algorithm set, or otherwise we wouldn't be able to
figure out that prefix. As we do not have a hash algorithm in many
cases, for example when handling null object IDs, this assumption cannot
always be fulfilled. We thus have a fallback in place that instead uses
`the_repository` to derive the hash function. This implicit dependency
is hidden away from callers and can be quite surprising, especially in
contexts where there may be no repository.

In theory, we can adapt those functions to always memcmp(3P) the whole
length of their hash arrays. But there exist a couple of sites where we
populate `struct object_id`s such that only the prefix of its hash that
is actually used by the hash algorithm is populated. The remaining bytes
are left uninitialized. The fact that those bytes are uninitialized also
leads to warnings under Valgrind in some places where we copy those
bytes.

Refactor callsites where we populate object IDs to always initialize all
bytes. This also allows us to get rid of `oidcpy_with_padding()`, for
one because the input is now fully initialized, and because `oidcpy()`
will now always copy the whole hash array.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
hash-ll.h
hash.h
hex.c
http-push.c
notes.c
object-file.c
oidtree.c
parallel-checkout.c