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
> +
next prev parent 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