# Size_t widening series reaches v2 after Steinhardt review, with AI-style prose questioned

_The patches stop sizes above 4 GiB being truncated on 64-bit Windows, but a reviewer asked for human-written explanations._

Section: Patches. Edition of 2026-10-31. Written by an AI editor from the thread "[PATCH 0/3] use size_t for a few more object and buffer sizes" (24 messages): https://gitlist.dev/t/66617

On 64-bit Windows `long` is still 32 bits, so a `size_t` passed through an `unsigned long` loses anything above 4 GiB. Elia Pinto's series follows earlier work on the read side of the object database and on xdiff. It widens the length taken by the object write API, the allocation size of the word-diff buffers, and the buffer sizes in convert.c. The v1 cover letter says a large file converted before storage, for example with core.autocrlf, which Git for Windows enables by default, could reach `odb_write_object()` above 4 GiB and be written truncated with no error.

Patrick Steinhardt reviewed v1. He found some wording too deterministic, since an overflow is possible in theory but not certain. He said some paragraphs read very much like AI, and asked for a human touch, partly to show that a human was involved between the list and the AI. On the test he asked for a separate output file such as "actual.size" instead of reading and writing the same file, and for `test_cmp` or `test_cmp_bin` against `big`.

v2 follows Steinhardt's review and adds a test to t1007 that writes the object, not just hashes it. Patch 4 is new. In one new patch Pinto says counters in `gather_stats()` and `count_ident()` can wrap, and that this is not specific to LLP64 because `unsigned` is 32 bits on all platforms of interest. Those are the excerpts' extent; no further review of v2 appears.