public inbox for git@vger.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Seyi Kuforiji <kuforiji98@gmail.com>
Cc: git@vger.kernel.org,  ps@pks.im
Subject: Re: [PATCH 2/5] builtin/rev-list: migrate missing_objects cleanup to oidmap_clear_with_free()
Date: Fri, 27 Feb 2026 16:09:04 -0800	[thread overview]
Message-ID: <xmqqcy1pohjz.fsf@gitster.g> (raw)
In-Reply-To: <20260227234213.17633-3-kuforiji98@gmail.com> (Seyi Kuforiji's message of "Sat, 28 Feb 2026 00:42:10 +0100")

Seyi Kuforiji <kuforiji98@gmail.com> writes:

> From: Seyi Kufoiji <kuforiji98@gmail.com>
>
> As part of the conversion away from oidmap_clear(), switch the
> missing_objects map to use oidmap_clear_with_free().
>
> missing_objects stores struct missing_objects_map_entry instances,
> which own an xstrdup()'d path string in addition to the container
> struct itself. Previously, rev-list manually freed entry->path
> before calling oidmap_clear(&missing_objects, true).
>
> Introduce a dedicated free callback and pass it to
> oidmap_clear_with_free(), consolidating entry teardown into a
> single place and making cleanup semantics explicit. This improves
> clarity and maintainability.
>
> Signed-off-by: Seyi Kuforiji <kuforiji98@gmail.com>
> ---
>  builtin/rev-list.c | 13 ++++++++++---
>  1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/builtin/rev-list.c b/builtin/rev-list.c
> index ddea8aa251..567dc5e7f5 100644
> --- a/builtin/rev-list.c
> +++ b/builtin/rev-list.c
> @@ -88,9 +88,17 @@ static int arg_print_omitted; /* print objects omitted by filter */
>  
>  struct missing_objects_map_entry {
>  	struct oidmap_entry entry;
> -	const char *path;
> +	char *path;
>  	unsigned type;
>  };
> +
> +static void free_missing_objects_entry(void *e)
> +{
> +	struct missing_objects_map_entry *entry =
> +		container_of(e, struct missing_objects_map_entry, entry);
> +	free(entry);
> +}
> +
>  static struct oidmap missing_objects;
>  enum missing_action {
>  	MA_ERROR = 0,    /* fail if any missing objects are encountered */
> @@ -935,10 +943,9 @@ int cmd_rev_list(int argc,
>  		while ((entry = oidmap_iter_next(&iter))) {
>  			print_missing_object(entry, arg_missing_action ==
>  							    MA_PRINT_INFO);
> -			free((void *)entry->path);
>  		}
>  
> -		oidmap_clear(&missing_objects, true);
> +		oidmap_clear_with_free(&missing_objects, free_missing_objects_entry);
>  	}

Hmph, maybe I am confused, but the shape and memory ownership of the
structure involved has not changed before or after this patch.  We
have bunch of missing_objects_map_entry instances that embeds
oidmap_entry in each of them, and we iterate over this oidmap,
enumerating all the missing_objects_map_entry instances.

In the original code, we used to not just clear the oidmap used to
hold these missing_objects_map_entry instances, but dropped the
string pointed at and owned by the .path member of them while
iterating.  With the new code, I can see the newer interface
oidmap_clear_with_free() being told how to reclaim resources held by
these missing_objects_map_entry instances, so it is a perfect place
to not just free the "shell" structure, but also the piece of memory
held by the .path member, isn't it?  It appears to me that the
string pointed at by .path is no longer freed, introducing a leak?

The above hardly convinces me of the claim in the proposed log
message that this change improves clarity nor maintainability.  I am
puzzled...

  reply	other threads:[~2026-02-28  0:09 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-27 23:42 [PATCH 0/5] oidmap: migrate cleanup to oidmap_clear_with_free() Seyi Kuforiji
2026-02-27 23:42 ` [PATCH 1/5] oidmap: make entry cleanup explicit in oidmap_clear Seyi Kuforiji
2026-02-27 23:42 ` [PATCH 2/5] builtin/rev-list: migrate missing_objects cleanup to oidmap_clear_with_free() Seyi Kuforiji
2026-02-28  0:09   ` Junio C Hamano [this message]
2026-02-27 23:42 ` [PATCH 3/5] list-objects-filter: use oidmap_clear_with_free() for cleanup Seyi Kuforiji
2026-02-27 23:42 ` [PATCH 4/5] odb: use oidmap_clear_with_free() to release replace_map entries Seyi Kuforiji
2026-02-27 23:42 ` [PATCH 5/5] sequencer: use oidmap_clear_with_free() for string_entry cleanup Seyi Kuforiji
2026-03-02 20:00 ` [PATCH v2 0/5] oidmap: migrate cleanup to oidmap_clear_with_free() Seyi Kuforiji
2026-03-02 20:00   ` [PATCH v2 1/5] oidmap: make entry cleanup explicit in oidmap_clear Seyi Kuforiji
2026-03-02 22:23     ` Junio C Hamano
2026-03-02 20:00   ` [PATCH v2 2/5] builtin/rev-list: migrate missing_objects cleanup to oidmap_clear_with_free() Seyi Kuforiji
2026-03-02 22:26     ` Junio C Hamano
2026-03-04  6:57     ` Patrick Steinhardt
2026-03-02 20:00   ` [PATCH v2 3/5] list-objects-filter: use oidmap_clear_with_free() for cleanup Seyi Kuforiji
2026-03-02 22:30     ` Junio C Hamano
2026-03-04  6:57       ` Patrick Steinhardt
2026-03-04 15:31         ` Junio C Hamano
2026-03-04 19:29           ` Seyi Kuforiji
2026-03-04 20:30             ` Junio C Hamano
2026-03-04 21:43               ` Junio C Hamano
2026-03-02 20:00   ` [PATCH v2 4/5] odb: use oidmap_clear_with_free() to release replace_map entries Seyi Kuforiji
2026-03-02 22:35     ` Junio C Hamano
2026-03-02 20:00   ` [PATCH v2 5/5] sequencer: use oidmap_clear_with_free() for string_entry cleanup Seyi Kuforiji
2026-03-02 22:38     ` Junio C Hamano
2026-03-04  6:57       ` Patrick Steinhardt
2026-03-05 10:05   ` [PATCH v3 0/2] oidmap: migrate cleanup to oidmap_clear_with_free() Seyi Kuforiji
2026-03-05 10:05     ` [PATCH v3 1/2] oidmap: make entry cleanup explicit in oidmap_clear Seyi Kuforiji
2026-03-05 10:05     ` [PATCH v3 2/2] builtin/rev-list: migrate missing_objects cleanup to oidmap_clear_with_free() Seyi Kuforiji
2026-03-05 14:27     ` [PATCH v3 0/2] oidmap: migrate " Patrick Steinhardt
2026-03-05 19:17     ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqcy1pohjz.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=kuforiji98@gmail.com \
    --cc=ps@pks.im \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox