Re: [PATCH v3 00/15] run-command API: pass functions & opts via struct

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 14, 2022, 15:53 UTC
Message-ID: <xmqq5ygmbdv5.fsf@gitster.g>
In-Reply-To: <221014.86y1tijv3b.gmgdl@evledraar.gmail.com>

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

Show 9 quoted lines

> You also had a related concern in 04/05 (which I'm taking the liberty of
> replying ot here):
>
> 	https://lore.kernel.org/git/a7463bc5-9a92-8f0f-c0ee-e72fbbeedc09@dunelm.org.uk/
>
> So, first I disagree with it "going in the wrong direction". We've been
> converting more things to size_t. For e.g. an "int nr_processes" we can
> expect that we'll want to e.g. have a corresponding "struct string_list"
> whose "nr" is a "size_t" (or similar aggregate types).

I do not quite see why that is relevant. We may create list of textual descriptions from list of processes, so we expect to be able to loop "for (int i = 0; i < nr_processes; i++)" and access i-th element of the corresponding string_list. As long as int is narrower than size_t (and it is wide enough to count the processes we are going to ever spawn) there is no issue, no? Also using signed type is so much more convenient to signal an error (imagine asking for a process's i that is between 0..nr_processes with some other key in your database, and having to answer "no such process known to me").

> By mixing the two we're mixing types forever with associated warnings (&
> suppressions).

That is a complaint about shortcomings of the tool that gives irrelevant warning, no? It is not a good reason to make the code worse. Compilers, editors, and linters are to serve the code, not the other way around.