All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Pranit Bauva <pranit.bauva@gmail.com>
Cc: git@vger.kernel.org, larsxschneider@gmail.com,
	chriscool@tuxfamily.org, christian.couder@gmail.com,
	peff@peff.net
Subject: Re: [PATCH] builtin/commit.c: memoize git-path for COMMIT_EDITMSG
Date: Mon, 23 May 2016 12:16:43 -0700	[thread overview]
Message-ID: <xmqq7feka8kk.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <1464027390-1512-1-git-send-email-pranit.bauva@gmail.com> (Pranit Bauva's message of "Mon, 23 May 2016 23:46:30 +0530")

Pranit Bauva <pranit.bauva@gmail.com> writes:

> This is a follow up commit for f932729c (memoize common git-path
> "constant" files, 10-Aug-2015).
>
> It serves two purposes:
>   1. It reduces the number of calls to git_path() .
>
>   2. It serves the benefits of using GIT_PATH_FUNC as mentioned in the
>      commit message of f932729c.

All of that is a good idea, but I have huge doubts about its use.

> diff --git a/builtin/commit.c b/builtin/commit.c
> index 391126e..ffa242c 100644
> --- a/builtin/commit.c
> +++ b/builtin/commit.c
> @@ -92,8 +92,10 @@ N_("If you wish to skip this commit, use:\n"
>  "Then \"git cherry-pick --continue\" will resume cherry-picking\n"
>  "the remaining commits.\n");
>  
> +static GIT_PATH_FUNC(git_path_commit_editmsg, "COMMIT_EDITMSG")
> +
>  static const char *use_message_buffer;
> -static const char commit_editmsg[] = "COMMIT_EDITMSG";
> +static const char commit_editmsg_path[] = git_path_commit_editmsg();

The function defined with the macro looks like

	const char *git_path_commit_editmsg(void)
        {
		static char *ret;
                if (!ret)
                	ret = git_pathdup("COMMIT_EDITMSG");
		return ret;
	}

so receiving its result to "const char v[]" looks somewhat
suspicious.

More importantly, when is this function evaluated and returned value
used to fill commit_editmsg_path[]?  In order for git_pathdup() to
produce a meaningful result, it needs to know where .git/ directory
is, which (roughly) means setup_git_dir() must have been called from
a callchain from main() somewhere already.

But I do not think the linker knows that fact.

> @@ -771,9 +773,9 @@ static int prepare_to_commit(const char *index_file, const char *prefix,
>  		hook_arg2 = "";
>  	}
>  

Instead, what you could do is to call git_path_commit_editmsg() when
you refer to that global variable whose initialization is suspect.

> -	s->fp = fopen_for_writing(git_path(commit_editmsg));
> +	s->fp = fopen_for_writing(commit_editmsg_path);

i.e.

	s->fp = fopen_for_writing(git_path_commit_editmsg());

As you can see in its definition, when the original code used to
call git_path(), it is safe to call git_path_commit_editmsg(),
because for the original git_path() to be correct, the code should
already have established where $GIT_DIR is, so it is safe to call
git_pathdup(), too.  Also, as you can see in its definition, calling
the function many times would not cause git_path() called many
times.  The first invocation will keep its value that is constant
within the program that works with a constant $GIT_DIR.

And you do not free its return value.

  reply	other threads:[~2016-05-23 19:16 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-23 18:16 [PATCH] builtin/commit.c: memoize git-path for COMMIT_EDITMSG Pranit Bauva
2016-05-23 19:16 ` Junio C Hamano [this message]
2016-05-24  5:54   ` Pranit Bauva
2016-05-24  6:35     ` Pranit Bauva
2016-05-24  8:11   ` Matthieu Moy
2016-05-24 11:41     ` Pranit Bauva
2016-05-24 22:25     ` Junio C Hamano
2016-05-24 19:19 ` [PATCH v2] " Pranit Bauva
2016-06-07 14:55   ` Pranit Bauva
2016-06-09  6:58     ` Jeff King
2016-06-09  9:54       ` Pranit Bauva
2016-06-09 17:04     ` 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=xmqq7feka8kk.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=chriscool@tuxfamily.org \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=larsxschneider@gmail.com \
    --cc=peff@peff.net \
    --cc=pranit.bauva@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 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.