All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "John Cai via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, John Cai <johncai86@gmail.com>
Subject: Re: [PATCH v2] receive-pack.c: consolidate find header logic
Date: Thu, 30 Dec 2021 15:01:12 -0800	[thread overview]
Message-ID: <xmqq1r1tofyf.fsf@gitster.g> (raw)
In-Reply-To: <pull.1125.v2.git.git.1640758765723.gitgitgadget@gmail.com> (John Cai via GitGitGadget's message of "Wed, 29 Dec 2021 06:19:25 +0000")

"John Cai via GitGitGadget" <gitgitgadget@gmail.com> writes:

> 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 using find_commit_header and replacing the logic in find_header.
>
> Introduce a new function find_header_max, 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.

find_header_max() is not the name of the function that finds the
largest header?  That is misleading.

<git-compat-util.h> defines a few helper functions that take a
counted string, and they are named with _mem() suffix after the name
of their NUL-terminated counterparts (if exists).  skip_prefix() has
skip_prefix_mem(), strip_suffix() has strip_suffix_mem().

find_header_mem() or something along that line, perhaps?

> diff --git a/commit.c b/commit.c
> index a348f085b2b..2ed115e04a0 100644
> --- a/commit.c
> +++ b/commit.c
> @@ -1631,12 +1631,14 @@ 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_max(const char *msg, const char *key,
> +			size_t len,
> +			size_t *out_len)

If <len> is meant to be the length part of <ptr,len> pair, we should
have it immediately after the <ptr> parameter.

	find_header_mem(const char *msg, size_t len,
        		const char *key, size_t *out_len)

That makes it clear to the readers that <msg, len> are close friends.

Also, I have a feeling that ...

>  {
>  	int key_len = strlen(key);
>  	const char *line = msg;
>  
> -	while (line) {
> +	while (line && (len == 0 || line < msg + len)) {

... we do not want this special casing of "if !len".  By making the
caller responsible to _always_ supply the length of msg, we can lose
the conditional.

>  		const char *eol = strchrnul(line, '\n');
>  
>  		if (line == eol)
> @@ -1653,6 +1655,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_max(msg, key, 0, out_len);

I.e. find_header_mem(msg, strlen(msg), key, out_len);

> diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
> index 9f4a0b816cf..b69ead8dcda 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)
>  {
> +	size_t out_len;
> +	const char *val = find_header_max(msg, key, len, &out_len);
> +
> +	if (val == NULL)
> +		return NULL;
> +
> +	if (next_line)
> +		*next_line = val + out_len + 1;
> +
> +	return xmemdupz(val, out_len);
>  }

Yup, something along that line.  Note that find_header() does make
it clear that the <msg, len> parameters form a pair.  We want to do
the same for the new helper.

  reply	other threads:[~2021-12-30 23:01 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 [this message]
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     ` [PATCH v4] " John Cai via GitGitGadget
2022-01-05 20:10       ` 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=xmqq1r1tofyf.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --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.