]> git.ipfire.org Git - thirdparty/git.git/commit
odb: teach read_blob_entry to use size_t
authorMatt Cooper <vtbassmatt@gmail.com>
Tue, 2 Nov 2021 15:46:08 +0000 (15:46 +0000)
committerJunio C Hamano <gitster@pobox.com>
Wed, 3 Nov 2021 18:22:27 +0000 (11:22 -0700)
commite9aa762cc72e6cf8fd76fefe5ca2b5064be1a821
tree5ac40538a76de8671af8b1dcc77822a22c1f99d6
parentb79541af7a1a7b7f2438f43196b1774d7b71e852
odb: teach read_blob_entry to use size_t

There is mixed use of size_t and unsigned long to deal with sizes in the
codebase. Recall that Windows defines unsigned long as 32 bits even on
64-bit platforms, meaning that converting size_t to unsigned long narrows
the range. This mostly doesn't cause a problem since Git rarely deals
with files larger than 2^32 bytes.

But adjunct systems such as Git LFS, which use smudge/clean filters to
keep huge files out of the repository, may have huge file contents passed
through some of the functions in entry.c and convert.c. On Windows, this
results in a truncated file being written to the workdir. I traced this to
one specific use of unsigned long in write_entry (and a similar instance
in write_pc_item_to_fd for parallel checkout). That appeared to be for
the call to read_blob_entry, which expects a pointer to unsigned long.

By altering the signature of read_blob_entry to expect a size_t,
write_entry can be switched to use size_t internally (which all of its
callers and most of its callees already used). To avoid touching dozens of
additional files, read_blob_entry uses a local unsigned long to call a
chain of functions which aren't prepared to accept size_t.

Helped-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Matt Cooper <vtbassmatt@gmail.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
entry.c
entry.h
parallel-checkout.c
t/t1051-large-conversion.sh