All of lore.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 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.