From: Patrick Steinhardt Date: Mon, 15 Jun 2026 08:35:40 GMT Subject: Re: [PATCH 2/6] object-file.c: use size_t for header lengths Message-ID: In-Reply-To: <809d83e46fb46baeb5d0dfcd12eb7fc63580eec4.1780593313.git.gitgitgadget@gmail.com> On Thu, Jun 04, 2026 at 05:15:08PM +0000, Philip Oakley via GitGitGadget wrote: > From: Philip Oakley > > Continue walking the code path for the >4GB `hash-object --literally` > test. The `hash_object_file_literally()` function internally uses both > `hash_object_file()` and `write_object_file_prepare()`. Both function > signatures use `unsigned long` rather than `size_t` for the mem buffer > sizes. Use `size_t` instead, for LLP64 compatibility. > > While at it, convert those function's object's header buffer length to > `size_t` for consistency. The value is already upcast to `uintmax_t` for > print format compatibility. One thing I was wondering is whether we should rather migrate to a size that is consistent across different platforms. We could e.g. `typedef uint64_t objsize_t` and then use that going forward. I guess the question though is whether that'd buy us anything. In other words, are there any platforms that we care about where `size_t` is only 32 bit wide? And would such platforms even be able to handle such large objects? Patrick