public inbox for git@vger.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Mirko Faina <mroik@delayed.space>
Cc: git@vger.kernel.org
Subject: Re: [PATCH v2] apply.c: fix -p argument parsing
Date: Mon, 09 Mar 2026 20:31:42 -0700	[thread overview]
Message-ID: <xmqqwlzkxsv5.fsf@gitster.g> (raw)
In-Reply-To: <20260310005408.2022216-1-mroik@delayed.space> (Mirko Faina's message of "Tue, 10 Mar 2026 01:54:07 +0100")

Mirko Faina <mroik@delayed.space> writes:

> "git apply" has an option -p that takes an integer as its argument.
> Unfortunately the function apply_option_parse_p() in charge of parsing
> this argument uses atoi() to convert from string to integer, which
> allows a non-digit after the number (e.g. "1q") to be silently ignored.
> As a consequence, an argument that does not begin with a digit silently
> becomes a zero. Despite this command working fine when a non-positive
> argument is passed, it might be useful for the end user to know that
> their input contains non-digits that might've been unintended.
>
> Replace atoi() with strtol_i() to catch malformed inputs.
>
> Signed-off-by: Mirko Faina <mroik@delayed.space>
> ---

>  apply.c                 |  3 ++-
>  t/t4103-apply-binary.sh | 19 +++++++++++++++++++
>  t/t4103/patch           | 16 ++++++++++++++++
>  3 files changed, 37 insertions(+), 1 deletion(-)
>  create mode 100644 t/t4103/patch

Curious.  It is true that we need to parse the p_value correctly
even when we are applying a binary patch, but the problem is not
limited to binary patches, is it?

> diff --git a/apply.c b/apply.c
> index b6dd1066a0..61df3bdcd0 100644
> --- a/apply.c
> +++ b/apply.c
> @@ -4981,7 +4981,8 @@ static int apply_option_parse_p(const struct option *opt,
>  
>  	BUG_ON_OPT_NEG(unset);
>  
> -	state->p_value = atoi(arg);
> +	if (strtol_i(arg, 10, &state->p_value) < 0 || state->p_value < 0)
> +		die("<num> has to be a non-negative integer");
>  	state->p_value_known = 1;
>  	return 0;
>  }

Sounds sensible.

I briefly wondered if it would have negative fallouts to change the
type of .p_value member to "unsigned int" and use strtol_ui() to
parse it, but the amount of work this part of the code needs to do
does not change that much, so such a change is of dubious value.
It looks like the above draws the line at the right place to stop.

Great execution.

> diff --git a/t/t4103-apply-binary.sh b/t/t4103-apply-binary.sh
> index 8e302a5a57..d9dc884946 100755
> --- a/t/t4103-apply-binary.sh
> +++ b/t/t4103-apply-binary.sh
> @@ -53,6 +53,25 @@ test_expect_success 'setup' '
>  	)
>  '
>  
> +test_expect_success 'git apply -p 1 patch' '
> +	test_when_finished "rm -rf result t" &&
> +	git apply -p 1 $TEST_DIRECTORY/t4103/patch &&
> +	ls -l | sed -e "/[[:space:]]t$/!d" >result &&
> +	test_line_count = 1 result
> +'

Is this saying "in the directory there must be only a single file
whose name is t?"  Wouldn't it be more readable and direct to do
something like

	test_path_is_dir t

or is there something more subtle going on here?

> +test_expect_success 'git apply -p malformed patch' '
> +	test_must_fail git apply -p malformed $TEST_DIRECTORY/t4103/patch
> +'
>
> +test_expect_success 'git apply -p 2q patch' '
> +	test_must_fail git apply -p 2q $TEST_DIRECTORY/t4103/patch
> +'

If this did not fail and patch gets applied with some p_value that
happens to be used when we fail to parse the number, then ...

> +test_expect_success 'git apply -p -1 patch' '
> +	test_must_fail git apply -p -1 $TEST_DIRECTORY/t4103/patch
> +'

... it would not be clear why this step fails.  Perhaps with that
same "unable to parse" p_value was used and this tried to create the
same file as the previous step already created, or we detected parse
failure.  We cannot tell.

It probably is a good idea to prepare for the worst by doing
something silly like

	test_when_finished "rm -f t/test/test test/test test" &&

at the beginning of each of these tests so that we would clean up
whatever we could leave behind?  I dunno.

>  test_expect_success 'stat binary diff -- should not fail.' \
>  	'git checkout main &&
>  	 git apply --stat --summary B.diff'
> diff --git a/t/t4103/patch b/t/t4103/patch
> new file mode 100644
> index 0000000000..c4511bb708
> --- /dev/null
> +++ b/t/t4103/patch
> @@ -0,0 +1,16 @@
> +From 90ad11d5b2d437e82d4d992f72fb44c2227798b5 Mon Sep 17 00:00:00 2001
> +From: Mroik <mroik@delayed.space>
> +Date: Mon, 9 Mar 2026 23:25:00 +0100
> +Subject: [PATCH] Test
> +
> +---
> + t/test/test | 0
> + 1 file changed, 0 insertions(+), 0 deletions(-)
> + create mode 100644 t/test/test
> +
> +diff --git a/t/test/test b/t/test/test
> +new file mode 100644
> +index 0000000000..e69de29bb2
> +-- 
> +2.53.0.851.ga537e3e6e9
> +

  reply	other threads:[~2026-03-10  3:31 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-09 23:26 [PATCH] apply.c: fix -p argument parsing Mirko Faina
2026-03-09 23:43 ` Junio C Hamano
2026-03-10  0:54 ` [PATCH v2] " Mirko Faina
2026-03-10  3:31   ` Junio C Hamano [this message]
2026-03-10  4:45     ` Mirko Faina
2026-03-10  5:06   ` [PATCH v3] " Mirko Faina
2026-03-10 13:13     ` Junio C Hamano
2026-03-13  0:16     ` Jeff King
2026-03-13  1:12       ` Jeff King
2026-03-13  1:29         ` Jeff King
2026-03-13  4:27         ` Junio C Hamano
2026-03-13  4:19       ` Junio C Hamano
2026-03-13  3:19     ` [PATCH v4] " Mirko Faina
2026-03-13  4:39       ` Junio C Hamano
2026-03-16  0:51       ` [PATCH] " Mirko Faina
2026-03-16  0:52         ` Mirko Faina
2026-03-16 19:56         ` Junio C Hamano
2026-03-15 17:22 ` Tian Yuchen
2026-03-15 17:56   ` Mirko Faina

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=xmqqwlzkxsv5.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=mroik@delayed.space \
    /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