[PATCH 0/2] archive, apply: do not truncate files of 4GiB or more

[Elia Pinto <gitter.spiros@gmail.com>]

Two more cases where, on platforms where "long" is 32 bits but size_t
is 64 bits (64-bit Windows), a file of 4GiB or more is written truncated
or corrupt without any error.

- 1/2 archive: tar and zip of a file written by streaming come out
  corrupt.
- 2/2 apply: the file being patched is written truncated with exit 0
  (also with --index and git am).

No new tests; both were verified by simulating the truncation at 16
bits, as described in the messages.

Regarding t5004, the existing test "zip archive with files bigger than
4GB" has been excluded where "long" is 32 bits (LONG_IS_64BIT) since
2017, because back then the object database couldn't read objects that
large. Today on 64-bit Windows it can, and with this series zip works
too. Thus, the guard could become SIZE_T_IS_64BIT to enable a real test
on Windows. Since I haven't run it on Windows, I'm offering this as a
follow-up or asking reviewers for an opinion.

With this series, the search for these truncations is finished. The
remaining warnings are not reachable: a 4GiB index, sizes bounded by
config or by the format, commits over 4GiB that already die.

It doesn't depend on the other series in flight and merges cleanly with
them. Based on master 50fe5cc63f.

Elia Pinto (2):
  archive: use size_t for the size of archive entries
  apply: use size_t for the size of the result written out

 apply.c       |  8 ++++----
 archive-tar.c | 10 +++++-----
 archive-zip.c | 16 ++++++++--------
 archive.h     |  2 +-
 4 files changed, 18 insertions(+), 18 deletions(-)


base-commit: 50fe5cc63f9cd6e89b87a2c9ccf96a444f4cfdb7
-- 
2.53.0