From: Elia Pinto Date: Sat, 31 Oct 2026 18:37:17 GMT Subject: Re: [PATCH 0/4] use size_t when parsing and checking objects Message-ID: <20261031183717.273904-1-gitter.spiros@gmail.com> In-Reply-To: On Sun, Nov 01, 2026 at 02:06:09AM +0900, Simon Richter wrote: > > This series continues the search for truncated sizes on platforms where > > "long" is 32 bits (Windows). It covers the functions that parse, verify, > > and check whole objects in memory: they take the size as an "unsigned > > long", while their callers have a size_t, so above 4GiB the size gets > > truncated. > Again, reminder that size_t is also 32 bit on 32-bit architectures, > because size_t is used for the size of in-memory objects. Agreed. On a 32-bit system, objects over 4GiB cannot be held in memory anyway. The mention of Windows in the cover letter refers to LLP64, where size_t is 64 bits but long is 32 bits, which is precisely the case this series fixes. > > Anything that is on disk can have a size that only fits into an off_t, > which is 64 bit if large file support is enabled, and 32 bit if it is > not. If large file support is disabled, opening a file larger than 2 GB > is supposed to fail (because you need to pass O_LARGEFILE, which is > defined only if large file support is enabled), but there is a chance > that an on-disk object got truncated, so that is not guaranteed. > > So, use size_t only for in-memory data, but if you are reading data from > disk piecewise, the total count of data processed needs to be an off_t. Indeed. This series only deals with buffers already entirely in memory (in check_object_signature(), fsck, parse_*_buffer(), and the message helpers), where size_t is the appropriate type. Your remark prompted me to take another look at the other patches. In pack-objects, the accumulated length that write_large_blob_data() tracks while writing the stream piece by piece was indeed a size_t. That fits your point precisely, so v2 of that patch, which I am sending as a reply to v1, uses off_t: https://lore.kernel.org/git/20261031180411.257932-1-gitter.spiros@gmail.com/ Thanks for the insightful review! Elia