public inbox for git@vger.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Lidong Yan <yldhome2d2@gmail.com>
Cc: Jinyao Guo <guo846@purdue.edu>,
	 Kristoffer Haugsbakk <kristofferhaugsbakk@fastmail.com>,
	 Josh Soref <gitgitgadget@gmail.com>,
	"git@vger.kernel.org" <git@vger.kernel.org>,
	 Alex <alexguo1023@gmail.com>
Subject: Re: [PATCH] Fix memory leak in function handle_content_type
Date: Sun, 15 Jun 2025 18:01:19 -0700	[thread overview]
Message-ID: <xmqqldps4i00.fsf@gitster.g> (raw)
In-Reply-To: <8C3C7F5F-9442-4C63-9280-D46A683C9F4D@gmail.com> (Lidong Yan's message of "Sun, 15 Jun 2025 20:55:08 +0800")

Lidong Yan <yldhome2d2@gmail.com> writes:

> Subject: Re: [PATCH] Fix memory leak in function handle_content_type

The subject should probably be something like

	Subject: [PATCH] mailinfo.c: plug memory leak in handle_content_type()

> May be using goto here would be better. Like:
>
> ---
> diff --git a/mailinfo.c b/mailinfo.c
> index ee4597da6b..83358b7517 100644
> --- a/mailinfo.c
> +++ b/mailinfo.c
> @@ -266,13 +266,14 @@ static void handle_content_type(struct mailinfo *mi, struct strbuf *line)
>                         error("Too many boundaries to handle");
>                         mi->input_error = -1;
>                         mi->content_top = &mi->content[MAX_BOUNDARIES] - 1;
> -                       return;
> +                       goto out;
>                 }
>                 *(mi->content_top) = boundary;
>                 boundary = NULL;
>         }
>         slurp_attr(line->buf, "charset=", &mi->charset);
>  
> +out:
>         if (boundary) {
>                 strbuf_release(boundary);
>                 free(boundary);
> —

Yup, that one looks good enough.

If we wanted to clean up this code path even further, I think the
first clean-up to do is to reconsider the use of "struct strbuf *"
(instead of "const char *") in *(mi->content_top).  strbuf is a fine
and less error-prone mechanism to use while you have to manipulate
character strings (like parsing from input line to formulate the
boundary string), but once this function computed what was asked by
the caller, the computed result (like the boundary string) almost
always do not need to be editable.  But such a code improvement is
totally outside the topic of this patch.


      reply	other threads:[~2025-06-16  1:01 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-13 16:52 [PATCH] Fix memory leak in function handle_content_type Alex via GitGitGadget
2025-06-13 16:59 ` Kristoffer Haugsbakk
2025-06-13 18:36   ` Jinyao Guo
2025-06-13 19:06     ` Junio C Hamano
2025-06-13 19:26       ` Jinyao Guo
2025-06-14 16:45         ` Junio C Hamano
2025-06-15 12:55         ` Lidong Yan
2025-06-16  1:01           ` Junio C Hamano [this message]

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=xmqqldps4i00.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=alexguo1023@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=guo846@purdue.edu \
    --cc=kristofferhaugsbakk@fastmail.com \
    --cc=yldhome2d2@gmail.com \
    /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