diff options
author | Matt Cooper <vtbassmatt@gmail.com> | 2021-11-02 15:46:08 +0000 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2021-11-03 11:22:27 -0700 |
commit | e9aa762cc72e6cf8fd76fefe5ca2b5064be1a821 (patch) | |
tree | 5ac40538a76de8671af8b1dcc77822a22c1f99d6 /send-pack.c | |
parent | t1051: introduce a smudge filter test for extremely large files (diff) | |
download | tgif-e9aa762cc72e6cf8fd76fefe5ca2b5064be1a821.tar.xz |
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>
Diffstat (limited to 'send-pack.c')
0 files changed, 0 insertions, 0 deletions