All of lore.kernel.org
 help / color / mirror / Atom feed
From: Taylor Blau <me@ttaylorr.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Drew DeVault <sir@cmpwn.com>, git@vger.kernel.org
Subject: Re: [PATCH v2] builtin/log.c: prepend "RFC" on --rfc
Date: Mon, 28 Aug 2023 19:21:57 -0400	[thread overview]
Message-ID: <ZO0sFWJLX8YaJ2F/@nand.local> (raw)
In-Reply-To: <xmqqa5ubi1nh.fsf@gitster.g>

On Mon, Aug 28, 2023 at 09:15:30AM -0700, Junio C Hamano wrote:
> In the current code before this patch, the rev.subject_prefix member
> holds one of:
>
>  * hardcoded "PATCH" in BSS (i.e. fmt_patch_subject_prefix)
>  * hardcoded "RFC PATCH" in BSS when "--rfc" is given
>  * value given to command line arg "--subject-prefix=<prefix>"
>  * value given to format.subjectprefix
>
> and the last one should be freed.  We are removing the second one
> and replacing it with whatever we will do when adding this feature
> so we should be able to make it freeable.  And I do not think it is
> hard to make the third one freeable.
>
> I wonder how far we can go to plug this leak by simply
>
>  - making subject_prefix_callback() xstrdup() its arg and free the
>    current value, unless it is the same pointer as
>    fmt_patch_subject_prefix, before assigning a new value, and
>
>  - making "format.subjectprefix" take the value in a temporary
>    variable from git_config_string(), call
>    subject_prefix_callback(), and free that temporary.

I am not super familiar with this code, so could easily be missing
something here, but I think that you can do this in a more direct way
like so:

--- 8< ---
diff --git a/builtin/log.c b/builtin/log.c
index 854216ee9c..f1c6c08f75 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -67,6 +67,7 @@ static const char *fmt_patch_subject_prefix = "PATCH";
 static int fmt_patch_name_max = FORMAT_PATCH_NAME_MAX_DEFAULT;
 static const char *fmt_pretty;
 static int format_no_prefix;
+static char *subject_prefix;

 static const char * const builtin_log_usage[] = {
 	N_("git log [<options>] [<revision-range>] [[--] <path>...]"),
@@ -362,6 +363,7 @@ static void cmd_log_init(int argc, const char **argv, const char *prefix,
 static int cmd_log_deinit(int ret, struct rev_info *rev)
 {
 	release_revisions(rev);
+	free(subject_prefix);
 	return ret;
 }

@@ -1463,32 +1465,27 @@ static int keep_callback(const struct option *opt, const char *arg, int unset)
 	return 0;
 }

-static int subject_prefix = 0;
-
 static int subject_prefix_callback(const struct option *opt, const char *arg,
 			    int unset)
 {
+	struct rev_info *revs = opt->value;
 	BUG_ON_OPT_NEG(unset);
-	subject_prefix = 1;
-	((struct rev_info *)opt->value)->subject_prefix = arg;
+
+	revs->subject_prefix = arg;
+
 	return 0;
 }

 static int rfc_callback(const struct option *opt, const char *arg, int unset)
 {
-	/*
-	 * The subject_prefix in rev_info is not heap-allocated except in this
-	 * specific case, so there is no obvious place to free it. Since this
-	 * value is retained for the lifetime of the process, we just
-	 * statically allocate storage for it here.
-	 */
-	static char *prefix;
+	struct rev_info *revs = opt->value;
+
 	BUG_ON_OPT_NEG(unset);
 	BUG_ON_OPT_ARG(arg);

-	free(prefix);
-	prefix = xstrfmt("RFC %s", ((struct rev_info *)opt->value)->subject_prefix);
-	return subject_prefix_callback(opt, prefix, unset);
+	free(subject_prefix);
+	subject_prefix = xstrfmt("RFC %s", revs->subject_prefix);
+	return subject_prefix_callback(opt, subject_prefix, unset);
 }

 static int numbered_cmdline_opt = 0;
--- >8 ---

since we already have cmd_log_deinit(), which currently just calls
`release_revisions()` and then propagates a return code.

We can't foist freeing the subject_prefix into release_revisions, since
(as noted above), sometimes the value will point into the program's BSS.

But the only time we care about free()-ing subject_prefix is when we
xstrdup() a new value into it, and the only place we do that is in
rfc_callback().

Thanks,
Taylor

  reply	other threads:[~2023-08-28 23:22 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-28 14:48 [PATCH v2] builtin/log.c: prepend "RFC" on --rfc Drew DeVault
2023-08-28 16:15 ` Junio C Hamano
2023-08-28 23:21   ` Taylor Blau [this message]
2023-08-28 23:53     ` 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=ZO0sFWJLX8YaJ2F/@nand.local \
    --to=me@ttaylorr.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=sir@cmpwn.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.