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 v6] receive-pack.c: consolidate find header logic
Date: Fri, 07 Jan 2022 23:11:07 -0800	[thread overview]
Message-ID: <xmqqwnja3do4.fsf@gitster.g> (raw)
In-Reply-To: <pull.1125.v6.git.git.1641499655700.gitgitgadget@gmail.com> (John Cai via GitGitGadget's message of "Thu, 06 Jan 2022 20:07:35 +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 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
> +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: It's possible for strchrnul() to scan beyond the range
> +	 * given by len. However, current callers are safe because they compute
> +	 * len by scanning a NUL-terminated block of memory starting at msg.
> +	 * Nonetheless, it would be better to ensure the function does not look
> +	 * at msg beyond the len provided by the caller.
> +	 */
> +	while (line && line < msg + len) {
>  		const char *eol = strchrnul(line, '\n');

Thanks; queued.

      parent reply	other threads:[~2022-01-08  7:11 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     ` [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 [this message]

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=xmqqwnja3do4.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.