On 9/3/2025 6:15 AM, Patrick Steinhardt wrote:
> On Sat, Aug 30, 2025 at 09:23:25PM +0000, Derrick Stolee via GitGitGadget wrote:
>> From: Derrick Stolee <stolee@xxxxxxxxx>
>>
>> midx-write.c has the DISABLE_SIGN_COMPARE_WARNINGS macro defined for a
>> few reasons, but the biggest one is the use of a signed
>> preferred_pack_idx member inside the write_midx_context struct. The code
>> currently uses -1 to indicate an unset preferred pack but pack int ids
>> are normally handled as uint32_t. There are also a few loops that search
>> for the preferred pack by name and those iterators will need updates to
>> uint32_t in the next change.
>>
>> For now, replace the use of -1 with a 'NO_PREFERRED_PACK' macro and an
>> equality check. The macro stores the max value of a uint32_t, so we
>> cannot store a preferred pack that appears last in a list of 2^32 total
>> packs, but that's expected to be unreasonable already. This improves the
>> range from 2^31 already.
>
> Tiny nit: the last sentence reads a bit funny. Maybe something like
> this?
>
> Furthermore, with this change we end up extending the range from
> 2^31 possible packs to 2^32-1.
That is better.
>> @@ -1040,7 +1042,9 @@ static int write_midx_internal(struct repository *r, const char *object_dir,
>> struct hashfile *f = NULL;
>> struct lock_file lk;
>> struct tempfile *incr;
>> - struct write_midx_context ctx = { 0 };
>> + struct write_midx_context ctx = {
>> + .preferred_pack_idx = NO_PREFERRED_PACK,
>> + };
>> int bitmapped_packs_concat_len = 0;
>> int pack_name_concat_len = 0;
>> int dropped_packs = 0;
>
> Why is this change needed? We didn't previously initialize
> `.preferred_pack_idx = -1` either.
I think the previous lack of initialization was incorrect. It happened
to work because it became initialized to -1 later _or_ its value of
zero was implicitly used when searching for a preferred pack.
I thought it prudent to set this value as the default instead of
implying that the 0th packfile was preferred.
Thanks,
-Stolee
