git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] Copy resolve_ref() return value for longer use

From
Junio C Hamano <gitster@pobox.com>
Date
Nov 13, 2011, 07:59 UTC
Message-ID
<7vobwgo3l5.fsf@alter.siamese.dyndns.org>
In-Reply-To
<CACsJy8ARAzNWjZfXwnNG0AprCFXLCkiDrE+eFj9icbeNX14xKw@mail.gmail.com>
Nguyen Thai Ngoc Duy <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
Show 12 quoted lines
> ... 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),
Previous: Nguyen Thai Ngoc DuyNext: Nguyễn Thái Ngọc Duy
Message 9 of 31 in “Re: git bug(?) for commit baf18fc261ca475343fe3cb9cd2c0dded4bc1bb7”
  1. Nguyen Thai Ngoc DuyNov 7, 2011
  2. Tony WangNov 7, 2011
  3. Nguyen Thai Ngoc DuyNov 7, 2011
  4. Tony WangNov 7, 2011
  5. Nguyen Thai Ngoc DuyNov 7, 2011
  6. Copy resolve_ref() return value for longer useNguyễn Thái Ngọc Duy, Nov 8, 2011
  7. Junio C HamanoNov 13, 2011
  8. Nguyen Thai Ngoc DuyNov 13, 2011
  9. Junio C HamanoNov 13, 2011
  10. 1/2 Convert many resolve_ref() calls to read_ref*() and ref_exists()Nguyễn Thái Ngọc Duy, Nov 13, 2011
  11. 2/2 Copy resolve_ref() return value for longer useNguyễn Thái Ngọc Duy, Nov 13, 2011
  12. Junio C HamanoNov 13, 2011
  13. Nguyen Thai Ngoc DuyNov 14, 2011
  14. Junio C HamanoNov 14, 2011
  15. Jeff KingNov 14, 2011
  16. Nguyen Thai Ngoc DuyNov 15, 2011
  17. 01/10 Allow resolve_ref() caller to decide whether to receive static bufferNguyễn Thái Ngọc Duy, Nov 15, 2011
  18. 02/10 cmd_merge: convert to single exit pointNguyễn Thái Ngọc Duy, Nov 15, 2011
  19. 03/10 merge: do not point "branch" to a resolve_ref()'s static bufferNguyễn Thái Ngọc Duy, Nov 15, 2011
  20. 04/10 commit: move resolve_ref() closer to where the return value is usedNguyễn Thái Ngọc Duy, Nov 15, 2011
  21. 05/10 checkout: do not try xstrdup() on NULLNguyễn Thái Ngọc Duy, Nov 15, 2011
  22. 06/10 reflog-walk.c: request allocated buffer from resolve_ref()Nguyễn Thái Ngọc Duy, Nov 15, 2011
  23. 07/10 receive-pack: request resolve_ref() to allocate new bufferNguyễn Thái Ngọc Duy, Nov 15, 2011
  24. 08/10 notes: request resolve_ref() to allocate new bufferNguyễn Thái Ngọc Duy, Nov 15, 2011
  25. 09/10 fmt-merge-msg: request resolve_ref() to allocate new bufferNguyễn Thái Ngọc Duy, Nov 15, 2011
  26. 10/10 branch: request resolve_ref() to allocate new bufferNguyễn Thái Ngọc Duy, Nov 15, 2011
  27. Junio C HamanoNov 15, 2011
  28. Junio C HamanoNov 13, 2011
  29. Tony WangDec 10, 2011
  30. Nguyen Thai Ngoc DuyDec 10, 2011
  31. Tony WangDec 11, 2011

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.