From: Johannes Schindelin Date: Tue, 16 Jun 2026 14:48:01 GMT Subject: Re: [PATCH 2/6] object-file.c: use size_t for header lengths Message-ID: <29ae7ae4-4ae7-2057-3273-d5024a893d2e@gmx.de> In-Reply-To: Hi Patrick, On Mon, 15 Jun 2026, Patrick Steinhardt wrote: > 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. No, the point of `size_t` is to represent what the current platform can handle in-memory. That cannot (and should not) be consolidated. > 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? There are ways to handle objects larger than 4GB on 32-bit platforms, via streaming. In those cases, what you need is `off_t`, not `size_t`. Obviously, there is a large class of problems with such setups. For example, you can forget about efficiently reconstructing a large Git object from a delta chain. If you cannot do that in-memory, trying to work around that limitation merely opens up the user for a world of pain. Ciao, Johannes