git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 0/4] use size_t when parsing and checking objects

From
Elia Pinto <gitter.spiros@gmail.com>
Date
Oct 31, 2026, 18:37 UTC
Message-ID
<20261031183717.273904-1-gitter.spiros@gmail.com>
In-Reply-To
<b6c3c811-cabf-4421-aab2-f6b4b30951c2@hogyros.de>
On Sun, Nov 01, 2026 at 02:06:09AM +0900, Simon Richter wrote:
Show 7 quoted lines
> > 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.

Show 7 quoted lines
>
> 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
Previous: Simon Richter
Message 7 of 7 in “use size_t when parsing and checking objects”
  1. 0/4 use size_t when parsing and checking objectsElia Pinto, Oct 31, 2026
  2. 1/4 object-file: use size_t in check_object_signature()Elia Pinto, Oct 31, 2026
  3. 2/4 fsck: use size_t for the size of objects to checkElia Pinto, Oct 31, 2026
  4. 3/4 object, commit, tag: use size_t when parsing object buffersElia Pinto, Oct 31, 2026
  5. 4/4 tag, fmt-merge-msg, ref-filter: use size_t for message buffersElia Pinto, Oct 31, 2026
  6. Simon RichterOct 31, 2026
  7. Elia PintoOct 31, 2026

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.