All of lore.kernel.org
 help / color / mirror / Atom feed
From: "John Cai via GitGitGadget" <gitgitgadget@gmail.com>
To: git@vger.kernel.org
Cc: John Cai <johncai86@gmail.com>, John Cai <johncai86@gmail.com>
Subject: [PATCH v4] receive-pack.c: consolidate find header logic
Date: Wed, 05 Jan 2022 15:21:37 +0000	[thread overview]
Message-ID: <pull.1125.v4.git.git.1641396098056.gitgitgadget@gmail.com> (raw)
In-Reply-To: <pull.1125.v3.git.git.1640931460758.gitgitgadget@gmail.com>

From: John Cai <johncai86@gmail.com>

There are two functions that have very similar logic of finding a header
value. find_commit_header, and find_header. We can conslidate the logic
by introducing a new function find_header_mem, which is equivalent to
find_commit_header except it takes a len parameter that determines how
many bytes will be read. find_commit_header and find_header can then both
call find_header_mem.

This reduces duplicate logic, as the logic for finding header values
can now all live in one place.

Signed-off-by: John Cai <johncai86@gmail.com>
---
    Consolidate find_header logic into one function
    
    This addresses the NEEDSWORK comment in builtin/receive-pack.c:
    
     /**
       * NEEDSWORK: reuse find_commit_header() from jk/commit-author-parsing
       * after dropping "_commit" from its name and possibly moving it out
       * of commit.c
       **/
    
    
    There are two functions that have very similar logic of finding a header
    value. find_commit_header, and find_header. We can conslidate the logic
    by introducing a new function find_header_mem, which is equivalent to
    find_commit_header except it takes a len parameter that determines how
    many bytes will be read. find_commit_header and find_header can then
    both call find_header_mem.
    
    This reduces duplicate logic, as the logic for finding header values can
    now all live in one place.
    
    Changes since v4:
    
     * added NEEDSWORK block detailing what needs to be done to clean up
       find_header_mem
    
    Changes since v3:
    
     * fixed verbiage in commit message
     * adjusted style of an if block (based on Junio's feedback)

Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-1125%2Fjohn-cai%2Fjc%2Freplace-find-header-v4
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-1125/john-cai/jc/replace-find-header-v4
Pull-Request: https://github.com/git/git/pull/1125

Range-diff vs v3:

 1:  463df42e7e0 ! 1:  a7b00022b00 receive-pack.c: consolidate find header logic
     @@ Commit message
      
          There are two functions that have very similar logic of finding a header
          value. find_commit_header, and find_header. We can conslidate the logic
     -    by using find_commit_header and replacing the logic in find_header.
     -
     -    Introduce a new function find_header_max, which is equivalent to
     +    by introducing a new function find_header_mem, which is equivalent to
          find_commit_header except it takes a len parameter that determines how
     -    many bytes to read. find_commit_header can then call find_header_max
     -    with 0 as the len.
     +    many bytes will be read. find_commit_header and find_header can then both
     +    call find_header_mem.
      
     -    This cleans up duplicate logic, as the logic for finding header values
     -    is now all in one place.
     +    This reduces duplicate logic, as the logic for finding header values
     +    can now all live in one place.
      
          Signed-off-by: John Cai <johncai86@gmail.com>
      
     @@ builtin/receive-pack.c: static char *prepare_push_cert_nonce(const char *path, t
      +	size_t out_len;
      +	const char *val = find_header_mem(msg, len, key, &out_len);
      +
     -+	if (val == NULL)
     ++	if (!val)
      +		return NULL;
      +
      +	if (next_line)
     @@ commit.c: struct commit_list **commit_list_append(struct commit *commit,
       	const char *line = msg;
       
      -	while (line) {
     ++	/*
     ++	 * NEEDSWORK: Between line[0] and msg[len], there may not be a LF nor NUL
     ++	 * at all, and strchrnul() will scan beyond the range we were given
     ++	 * Make this operation safer and abide by the contract to only read up to len.
     ++	 */
      +	while (line && line < msg + len) {
       		const char *eol = strchrnul(line, '\n');
       


 builtin/receive-pack.c | 33 ++++++++++-----------------------
 commit.c               | 14 ++++++++++++--
 commit.h               |  5 +++++
 3 files changed, 27 insertions(+), 25 deletions(-)

diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index 9f4a0b816cf..5c2732a0d07 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -581,32 +581,19 @@ static char *prepare_push_cert_nonce(const char *path, timestamp_t stamp)
 	return strbuf_detach(&buf, NULL);
 }
 
-/*
- * NEEDSWORK: reuse find_commit_header() from jk/commit-author-parsing
- * after dropping "_commit" from its name and possibly moving it out
- * of commit.c
- */
 static char *find_header(const char *msg, size_t len, const char *key,
 			 const char **next_line)
 {
-	int key_len = strlen(key);
-	const char *line = msg;
-
-	while (line && line < msg + len) {
-		const char *eol = strchrnul(line, '\n');
-
-		if ((msg + len <= eol) || line == eol)
-			return NULL;
-		if (line + key_len < eol &&
-		    !memcmp(line, key, key_len) && line[key_len] == ' ') {
-			int offset = key_len + 1;
-			if (next_line)
-				*next_line = *eol ? eol + 1 : eol;
-			return xmemdupz(line + offset, (eol - line) - offset);
-		}
-		line = *eol ? eol + 1 : NULL;
-	}
-	return NULL;
+	size_t out_len;
+	const char *val = find_header_mem(msg, len, key, &out_len);
+
+	if (!val)
+		return NULL;
+
+	if (next_line)
+		*next_line = val + out_len + 1;
+
+	return xmemdupz(val, out_len);
 }
 
 /*
diff --git a/commit.c b/commit.c
index a348f085b2b..5ece03e6373 100644
--- a/commit.c
+++ b/commit.c
@@ -1631,12 +1631,18 @@ struct commit_list **commit_list_append(struct commit *commit,
 	return &new_commit->next;
 }
 
-const char *find_commit_header(const char *msg, const char *key, size_t *out_len)
+const char *find_header_mem(const char *msg, size_t len,
+			const char *key, size_t *out_len)
 {
 	int key_len = strlen(key);
 	const char *line = msg;
 
-	while (line) {
+	/*
+	 * NEEDSWORK: Between line[0] and msg[len], there may not be a LF nor NUL
+	 * at all, and strchrnul() will scan beyond the range we were given
+	 * Make this operation safer and abide by the contract to only read up to len.
+	 */
+	while (line && line < msg + len) {
 		const char *eol = strchrnul(line, '\n');
 
 		if (line == eol)
@@ -1653,6 +1659,10 @@ const char *find_commit_header(const char *msg, const char *key, size_t *out_len
 	return NULL;
 }
 
+const char *find_commit_header(const char *msg, const char *key, size_t *out_len)
+{
+	return find_header_mem(msg, strlen(msg), key, out_len);
+}
 /*
  * Inspect the given string and determine the true "end" of the log message, in
  * order to find where to put a new Signed-off-by trailer.  Ignored are
diff --git a/commit.h b/commit.h
index 3ea32766bcb..38cc5426615 100644
--- a/commit.h
+++ b/commit.h
@@ -290,12 +290,17 @@ void free_commit_extra_headers(struct commit_extra_header *extra);
 
 /*
  * Search the commit object contents given by "msg" for the header "key".
+ * Reads up to "len" bytes of "msg".
  * Returns a pointer to the start of the header contents, or NULL. The length
  * of the header, up to the first newline, is returned via out_len.
  *
  * Note that some headers (like mergetag) may be multi-line. It is the caller's
  * responsibility to parse further in this case!
  */
+const char *find_header_mem(const char *msg, size_t len,
+			const char *key,
+			size_t *out_len);
+
 const char *find_commit_header(const char *msg, const char *key,
 			       size_t *out_len);
 

base-commit: c8b2ade48c204690119936ada89cd938c476c5c2
-- 
gitgitgadget

  parent reply	other threads:[~2022-01-05 15:21 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-27 18:26 [PATCH 0/2] Consolidate find_header logic into one function John Cai via GitGitGadget
2021-12-27 18:26 ` [PATCH 1/2] receive-pack.c: consolidate find header logic John Cai via GitGitGadget
2021-12-27 22:33   ` Junio C Hamano
2021-12-27 18:26 ` [PATCH 2/2] commit.c: rename find_commit_header to find_header John Cai via GitGitGadget
2021-12-29  6:19 ` [PATCH v2] receive-pack.c: consolidate find header logic John Cai via GitGitGadget
2021-12-30 23:01   ` Junio C Hamano
2021-12-31  6:17   ` [PATCH v3] " John Cai via GitGitGadget
2022-01-04  1:56     ` Junio C Hamano
2022-01-04 15:12       ` John Cai
2022-01-05 15:21     ` John Cai via GitGitGadget [this message]
2022-01-05 20:10       ` [PATCH v4] " Junio C Hamano
2022-01-06  0:51       ` [PATCH v5] " John Cai via GitGitGadget
2022-01-06 19:40         ` Junio C Hamano
2022-01-06 20:07         ` [PATCH v6] " John Cai via GitGitGadget
2022-01-08  4:54           ` John Cai
2022-01-08  7:11           ` 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=pull.1125.v4.git.git.1641396098056.gitgitgadget@gmail.com \
    --to=gitgitgadget@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=johncai86@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.