Re: [PATCH v2 08/27] revisions API users: use release_revisions() needing "{ 0 }" init

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 24, 2022, 17:39 UTC
Message-ID: <xmqqwngji72a.fsf@gitster.g>
In-Reply-To: <220324.868rszmga6.gmgdl@evledraar.gmail.com>

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

Show 24 quoted lines

> On Wed, Mar 23 2022, Junio C Hamano wrote:
>
>> Ævar Arnfjörð Bjarmason  <avarab@gmail.com> writes:
>>
>>> Use release_revisions() to various users of "struct rev_list" which
>>> need to have their "struct rev_info" zero-initialized before we can
>>> start using it. In all of these cases we might "goto cleanup" (or equivalent),
>>
>> I didn't look at the bisect code, but the bundle one looks iffy from
>> the point of view of API cleanliness.  If we have not yet called
>> repo_init_revisions() on a revs, we should refrain from calling
>> release_revisions() on it in the first place, no?
>
> It could be avoided, but I'd really prefer not to for this series.
>
> repo_init_revisions() is a non-trivial function, and changing the
> various bits in this series that can easily have a "goto" pattern
> because we assume that { 0 }-init'd is safe to pass to
> release_revisions() would be a larger change...
>
> We assume that in a lot of other destructors throughout the codebase, I
> figured we could leave this for later.
>
> Is that OK with you?

Not really. If you introduce "#define REV_INFO_INIT { 0 }", perhaps, though.

Without such a mechanism to clearly say "here is what we initialize a rev_info", the first call to repo_init_revisions() looks like the place that initializes a rev_info, and call to release_revisions() on a rev_info that did not go through repo_init_revisions() looks like a call to free() of a pointer that hasn't been assigned the result from an allocation from the heap. That is where my "iffy from the API cleanliness POV" comes from.