Re: [PATCH v2 2/4] string-list: replace negative index encoding with "exact_match" parameter

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 25, 2025, 13:33 UTC
Message-ID: <xmqq5xd6irmu.fsf@gitster.g>
In-Reply-To: <20250925025040.GB3202669@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 5 quoted lines

> Yes, but it's much harder to wrap a size_t, especially if the code is
> allocating as it goes (e.g., a loop expanding an array). Because if
> expanding your allocation from "n" to "n+k" items will overflow, then
> that implies the current allocation is within "k" items of filling up
> the entire memory space.

We'd be protecting ourselves by noticing that n+k wraps around with st_add() and friends, and relying on malloc() and realloc() to notice and signal an error. Use of size_t to count the number of things that are getting allocated is not making these any easier to do compared to the case you were counting in "int", no? Either way we'd need to be careful.

Show 6 quoted lines

> But if we use size_t inside string_list, say, and you do this:
>
>    for (int i = 0; i < list.nr; i++)
> 	printf("got: %s", list->items[i].string);
>
> Now we have another problem.

It is obvious that in order to count up from 0 to list.nr, you'd better use a counter variable of the typeof(list.nr) or manage the wraparound yourself. So I do not see what is new here. My point was that use of size_t to _count_ the strings in the string list is where the problem stems from.

So, I still do not buy into the religion or superstition that things must be counted in size_t yet.