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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).