From: Tony Wang <wwwjfy@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Nguyen Thai Ngoc Duy <pclouds@gmail.com>, git@vger.kernel.org
Subject: Re: [PATCH] Copy resolve_ref() return value for longer use
Date: Sat, 10 Dec 2011 11:43:24 +0800 [thread overview]
Message-ID: <626C086D699644D181B9FA573EDFFCA6@gmail.com> (raw)
In-Reply-To: <7vobwgo3l5.fsf@alter.siamese.dyndns.org>
Hi,
I don't know about the procedure, but wonder is any one following this?
--
BR,
Tony Wang
On Sunday, November 13, 2011 at 15:59, Junio C Hamano wrote:
> Nguyen Thai Ngoc Duy <pclouds@gmail.com (mailto:pclouds@gmail.com)> writes:
>
> > I went through all of them. Most of them only checks if return value
> > is NULL, or does one-time string comparison. Others do xstrdup() to
> > save the return value. Will update the patch message to reflect this.
>
>
>
> Thanks. Given your analysis, I think the potential change I alluded to to
> return allocated memory from the function is probably overkill in the
> current state of the code.
>
> But as the codepaths around the existing callsites evolve, some of these
> call sites that are not problematic in today's code can become problematic
> if we are not careful. I was primarily wondering if an updated API could
> force us to be careful when making future changes.
>
> And a change along the lines of your suggestion
>
> > ... Though if you don't mind a bigger patch, we could turn
> >
> > const char *resolve_ref(const char *path, const char *sha1, int
> > reading, int *flag);
> >
> > to
> >
> > int resolve_ref(const char *path, const char *sha1, int reading, int
> > *flag, char **ref);
> >
> > where *ref is the current return value and is only allocated by
> > resolve_ref() if ref != NULL.
>
>
>
> might be one such updated API that makes mistakes harder to make. I dunno.
>
> But if we were to go that route, as the first step, it might make sense to
> rewrite "only checks if it returns NULL and uses sha1" callers to call
> either read_ref() or ref_exists(), so that we do not have to worry about
> leaking at such callers when we later decide to return allocated memory
> from resolve_ref().
>
>
> builtin/branch.c | 3 +--
> builtin/merge.c | 4 ++--
> 2 files changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/builtin/branch.c b/builtin/branch.c
> index 51ca6a0..94948a4 100644
> --- a/builtin/branch.c
> +++ b/builtin/branch.c
> @@ -565,7 +565,6 @@ static int print_ref_list(int kinds, int detached, int verbose, int abbrev, stru
> static void rename_branch(const char *oldname, const char *newname, int force)
> {
> struct strbuf oldref = STRBUF_INIT, newref = STRBUF_INIT, logmsg = STRBUF_INIT;
> - unsigned char sha1[20];
> struct strbuf oldsection = STRBUF_INIT, newsection = STRBUF_INIT;
> int recovery = 0;
>
> @@ -577,7 +576,7 @@ static void rename_branch(const char *oldname, const char *newname, int force)
> * Bad name --- this could be an attempt to rename a
> * ref that we used to allow to be created by accident.
> */
> - if (resolve_ref(oldref.buf, sha1, 1, NULL))
> + if (ref_exists(oldref.buf))
> recovery = 1;
> else
> die(_("Invalid branch name: '%s'"), oldname);
> diff --git a/builtin/merge.c b/builtin/merge.c
> index dffd5ec..42b4f9e 100644
> --- a/builtin/merge.c
> +++ b/builtin/merge.c
> @@ -420,7 +420,7 @@ static struct object *want_commit(const char *name)
> static void merge_name(const char *remote, struct strbuf *msg)
> {
> struct object *remote_head;
> - unsigned char branch_head[20], buf_sha[20];
> + unsigned char branch_head[20];
> struct strbuf buf = STRBUF_INIT;
> struct strbuf bname = STRBUF_INIT;
> const char *ptr;
> @@ -479,7 +479,7 @@ static void merge_name(const char *remote, struct strbuf *msg)
> strbuf_addstr(&truname, "refs/heads/");
> strbuf_addstr(&truname, remote);
> strbuf_setlen(&truname, truname.len - len);
> - if (resolve_ref(truname.buf, buf_sha, 1, NULL)) {
> + if (ref_exists(truname.buf)) {
> strbuf_addf(msg,
> "%s\t\tbranch '%s'%s of .\n",
> sha1_to_hex(remote_head->sha1),
next prev parent reply other threads:[~2011-12-10 3:50 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <BC404302028E4B6F8F2C27DC8E63545F@gmail.com>
2011-11-07 9:30 ` git bug(?) for commit baf18fc261ca475343fe3cb9cd2c0dded4bc1bb7 Nguyen Thai Ngoc Duy
2011-11-07 9:48 ` Tony Wang
2011-11-07 10:41 ` Nguyen Thai Ngoc Duy
2011-11-07 11:02 ` Tony Wang
2011-11-07 11:21 ` Nguyen Thai Ngoc Duy
2011-11-08 2:30 ` [PATCH] Copy resolve_ref() return value for longer use Nguyễn Thái Ngọc Duy
2011-11-13 5:57 ` Junio C Hamano
2011-11-13 7:09 ` Nguyen Thai Ngoc Duy
2011-11-13 7:59 ` Junio C Hamano
2011-11-13 10:22 ` [PATCH 1/2] Convert many resolve_ref() calls to read_ref*() and ref_exists() Nguyễn Thái Ngọc Duy
2011-11-13 10:22 ` [PATCH 2/2] Copy resolve_ref() return value for longer use Nguyễn Thái Ngọc Duy
2011-11-13 20:41 ` Junio C Hamano
2011-11-14 3:32 ` Nguyen Thai Ngoc Duy
2011-11-14 4:03 ` Junio C Hamano
2011-11-14 11:24 ` Jeff King
2011-11-15 6:06 ` Nguyen Thai Ngoc Duy
2011-11-15 6:07 ` [PATCH 01/10] Allow resolve_ref() caller to decide whether to receive static buffer Nguyễn Thái Ngọc Duy
2011-11-15 6:07 ` [PATCH 02/10] cmd_merge: convert to single exit point Nguyễn Thái Ngọc Duy
2011-11-15 6:07 ` [PATCH 03/10] merge: do not point "branch" to a resolve_ref()'s static buffer Nguyễn Thái Ngọc Duy
2011-11-15 6:07 ` [PATCH 04/10] commit: move resolve_ref() closer to where the return value is used Nguyễn Thái Ngọc Duy
2011-11-15 6:07 ` [PATCH 05/10] checkout: do not try xstrdup() on NULL Nguyễn Thái Ngọc Duy
2011-11-15 6:07 ` [PATCH 06/10] reflog-walk.c: request allocated buffer from resolve_ref() Nguyễn Thái Ngọc Duy
2011-11-15 6:07 ` [PATCH 07/10] receive-pack: request resolve_ref() to allocate new buffer Nguyễn Thái Ngọc Duy
2011-11-15 6:07 ` [PATCH 08/10] notes: " Nguyễn Thái Ngọc Duy
2011-11-15 6:07 ` [PATCH 09/10] fmt-merge-msg: " Nguyễn Thái Ngọc Duy
2011-11-15 6:07 ` [PATCH 10/10] branch: " Nguyễn Thái Ngọc Duy
2011-11-15 7:09 ` [PATCH 01/10] Allow resolve_ref() caller to decide whether to receive static buffer Junio C Hamano
2011-11-13 20:30 ` [PATCH 1/2] Convert many resolve_ref() calls to read_ref*() and ref_exists() Junio C Hamano
2011-12-10 3:43 ` Tony Wang [this message]
2011-12-10 4:48 ` [PATCH] Copy resolve_ref() return value for longer use Nguyen Thai Ngoc Duy
2011-12-11 2:28 ` Tony Wang
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=626C086D699644D181B9FA573EDFFCA6@gmail.com \
--to=wwwjfy@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=pclouds@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.