summaryrefslogtreecommitdiff
path: root/send-pack.c
diff options
context:
space:
mode:
authorLibravatar Matt Cooper <vtbassmatt@gmail.com>2021-11-02 15:46:08 +0000
committerLibravatar Junio C Hamano <gitster@pobox.com>2021-11-03 11:22:27 -0700
commite9aa762cc72e6cf8fd76fefe5ca2b5064be1a821 (patch)
tree5ac40538a76de8671af8b1dcc77822a22c1f99d6 /send-pack.c
parentt1051: introduce a smudge filter test for extremely large files (diff)
downloadtgif-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