Re: [PATCH 2/6] object-file.c: use size_t for header lengths
- From
Patrick Steinhardt <ps@pks.im>
- Date
- Jun 15, 2026, 08:35 UTC
- Message-ID
- <ai-5XO9gsc_HdMFX@pks.im>
- In-Reply-To
- <809d83e46fb46baeb5d0dfcd12eb7fc63580eec4.1780593313.git.gitgitgadget@gmail.com>
On Thu, Jun 04, 2026 at 05:15:08PM +0000, Philip Oakley via GitGitGadget wrote:
Show 11 quoted lines
> From: Philip Oakley <philipoakley@iee.email> > > 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