public inbox for git@vger.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Abraham Samuel Adekunle <abrahamadekunle50@gmail.com>
Cc: git@vger.kernel.org, "Patrick Steinhardt" <ps@pks.im>,
	"Phillip Wood" <phillip.wood123@gmail.com>,
	"SZEDER Gábor" <szeder.dev@gmail.com>,
	"Christian Couder" <christian.couder@gmail.com>,
	"Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com>,
	"Ben Knoble" <ben.knoble@gmail.com>,
	"Karthik Nayak" <karthik.188@gmail.com>,
	"Lucas Seiki Oshiro" <lucasseikioshiro@gmail.com>,
	"Chandra Pratap" <chandrapratap3519@gmail.com>
Subject: Re: [PATCH v4 2/4] add-patch: modify patch_update_file() signature
Date: Fri, 13 Feb 2026 15:33:59 -0800	[thread overview]
Message-ID: <xmqqms1ci5g8.fsf@gitster.g> (raw)
In-Reply-To: <906f25e184d744f9d23681600a0d9e440b7f07df.1771015581.git.abrahamadekunle50@gmail.com> (Abraham Samuel Adekunle's message of "Fri, 13 Feb 2026 23:10:48 +0100")

Abraham Samuel Adekunle <abrahamadekunle50@gmail.com> writes:

> -static int patch_update_file(struct add_p_state *s,
> -			     struct file_diff *file_diff)
> +static ssize_t patch_update_file(struct add_p_state *s, size_t idx)

Why ssize_t?  Are we going to handle that many hunks that we do not
expect to fit in a platform natural "int" type?  If we are not doing
anything about "idx" being more than half the type, which apparently
is the case ...

>  {
>  	size_t hunk_index = 0;
>  	ssize_t i, undecided_previous, undecided_next, rendered_hunk_index = -1;
>  	struct hunk *hunk;
>  	char ch;
>  	struct child_process cp = CHILD_PROCESS_INIT;
> -	int colored = !!s->colored.len, quit = 0, use_pager = 0;
> +	int colored = !!s->colored.len, use_pager = 0;
>  	enum prompt_mode_type prompt_mode_type;
> +	struct file_diff *file_diff = s->file_diff + idx;
> +	ssize_t patch_update_resp = (ssize_t)idx;

... with the cast that is not checked here, wouldn't it make sense
to just use the platform natural "int" everywhere?  Your code is not
"safe" either way.  I do not think we expect to handle 2 billion
hunks, so even on 32-bit platforms, platform natural "int" should be
plenty.  Instead of religiously using size_t and ssize_t to count
things without extra care, I'd rather see us check the error
condition for real, if that is what we really care about (and that
can still be done while leaving the codebase cleaner by sticking to
the platform natural "int").

Enough ranting.  Anyway.

If we really are bothered that we cannot handle 3 billion hunks, we
could avoid losing half the number range by returning
s->file_diff.file_diff_nr (which is one more than there are elements
in s->file_diff[] array) or ((size_t)-1).  That would allow us to
return size_t from here.  I care about this a bit more than "why use
size_t when int is perfectly fine", because some platforms that are
not quite POSIX can have ssize_t that is not as wide as size_t.

  reply	other threads:[~2026-02-13 23:34 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-23 11:56 [RFC PATCH 0/1] add-patch: Allow reworking with a file after deciding on its hunks Abraham Samuel Adekunle
2026-01-23 11:58 ` [RFC PATCH 1/1] add-patch: Allow reworking with a file after deciding on all " Abraham Samuel Adekunle
2026-01-23 16:38   ` Junio C Hamano
2026-01-23 21:43     ` Samuel Abraham
2026-01-27 15:43 ` [PATCH v2 0/1] Allow reworking with a file when making hunk decisions Abraham Samuel Adekunle
2026-01-27 15:45   ` [PATCH v2 1/1] Allow reworking with a file after deciding on all its hunks Abraham Samuel Adekunle
2026-01-27 20:48     ` Junio C Hamano
2026-01-28 11:26       ` Samuel Abraham
2026-01-30  9:22         ` Samuel Abraham
2026-01-30 16:29           ` Junio C Hamano
2026-01-30 17:36             ` Samuel Abraham
2026-01-31 19:25           ` Junio C Hamano
2026-02-02 11:14             ` Samuel Abraham
2026-02-02 17:26               ` Junio C Hamano
2026-02-03  9:55                 ` Samuel Abraham
2026-01-27 17:04   ` [PATCH v2 0/1] Allow reworking with a file when making hunk decisions Junio C Hamano
2026-01-28  9:49     ` Samuel Abraham
2026-02-06 15:52   ` [PATCH v3 0/3] introduce new option `rework-with-file` Abraham Samuel Adekunle
2026-02-06 15:54     ` [PATCH v3 1/3] interactive -p: add new `--rework-with-file` flag to interactive machinery Abraham Samuel Adekunle
2026-02-06 18:25       ` Junio C Hamano
2026-02-06 20:21         ` Samuel Abraham
2026-02-06 15:56     ` [PATCH v3 2/3] add-patch: Allow interfile navigation when selecting hunks Abraham Samuel Adekunle
2026-02-06 18:35       ` Junio C Hamano
2026-02-06 20:22         ` Samuel Abraham
2026-02-06 18:54       ` Junio C Hamano
2026-02-06 20:32         ` Samuel Abraham
2026-02-06 19:21       ` Junio C Hamano
2026-02-06 20:37         ` Samuel Abraham
2026-02-12 10:32         ` Samuel Abraham
2026-02-12 17:25           ` Junio C Hamano
2026-02-12 21:13             ` Samuel Abraham
2026-02-12 21:31               ` Junio C Hamano
2026-02-12 22:20                 ` Samuel Abraham
2026-02-06 15:57     ` [PATCH v3 3/3] add-patch: Allow proper 'git apply' when using the --rework-with-file flag Abraham Samuel Adekunle
2026-02-06 19:02       ` Junio C Hamano
2026-02-06 20:39         ` Samuel Abraham
2026-02-06 19:19     ` [PATCH v3 0/3] introduce new option `rework-with-file` Junio C Hamano
2026-02-06 20:40       ` Samuel Abraham
2026-02-13 22:08     ` [PATCH v4 0/4] introduce new option `--auto-advance` Abraham Samuel Adekunle
2026-02-13 22:09       ` [PATCH v4 1/4] interactive -p: add new `--auto-advance` flag Abraham Samuel Adekunle
2026-02-13 23:04         ` Junio C Hamano
2026-02-14  9:16           ` Samuel Abraham
2026-02-13 22:10       ` [PATCH v4 2/4] add-patch: modify patch_update_file() signature Abraham Samuel Adekunle
2026-02-13 23:33         ` Junio C Hamano [this message]
2026-02-14 10:14           ` Samuel Abraham
2026-02-13 22:11       ` [PATCH v4 3/4] add-patch: allow all-or-none application of patches Abraham Samuel Adekunle
2026-02-13 22:12       ` [PATCH v4 4/4] add-patch: allow interfile navigation when selecting hunks Abraham Samuel Adekunle
2026-02-14 11:01       ` [PATCH v5 0/4] introduce new option `--auto-advance` Abraham Samuel Adekunle
2026-02-14 11:03         ` [PATCH v5 1/4] interactive -p: add new `--auto-advance` flag Abraham Samuel Adekunle
2026-02-14 11:04         ` [PATCH v5 2/4] add-patch: modify patch_update_file() signature Abraham Samuel Adekunle
2026-02-14 11:06         ` [PATCH v5 3/4] add-patch: allow all-or-none application of patches Abraham Samuel Adekunle
2026-02-14 11:06         ` [PATCH v5 4/4] add-patch: allow interfile navigation when selecting hunks Abraham Samuel Adekunle
2026-02-20 22:32         ` [PATCH v5 0/4] introduce new option `--auto-advance` Junio C Hamano
2026-02-21  9:06           ` Samuel Abraham

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=xmqqms1ci5g8.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=abrahamadekunle50@gmail.com \
    --cc=ben.knoble@gmail.com \
    --cc=chandrapratap3519@gmail.com \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=karthik.188@gmail.com \
    --cc=kristofferhaugsbakk@fastmail.com \
    --cc=lucasseikioshiro@gmail.com \
    --cc=phillip.wood123@gmail.com \
    --cc=ps@pks.im \
    --cc=szeder.dev@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox