From: Elia Pinto <gitter.spiros@gmail.com>
To: git@vger.kernel.org, Patrick Steinhardt <ps@pks.im>
Cc: "Johannes Schindelin" <Johannes.Schindelin@gmx.de>,
"Jeff King" <peff@peff.net>, "Junio C Hamano" <gitster@pobox.com>,
"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Subject: Re: [PATCH v2 4/4] convert: use size_t for text statistics and ident counts
Date: Sat, 31 Oct 2026 11:16:19 +0100 [thread overview]
Message-ID: <20261031101619.172770-2-gitter.spiros@gmail.com> (raw)
In-Reply-To: <auSDKKHJONZjx2LX@pks.im>
On Fri, Oct 30, 2026 at 12:44:40PM +0100, Patrick Steinhardt wrote:
> > gather_stats() counts NULs, CRs, LFs, CRLFs and (non)printable
> > characters in "unsigned" fields of struct text_stat, and
> > count_ident() counts "$Id$" markers in an "int". Now that the buffer
> > sizes they work on are size_t, a large enough buffer overflows them.
>
> This sounds a bit too deterministic: it doesn't necessarily overflow
> them, but the possibility exists in theory.
Indeed, it's a theoretical possibility rather than something that
automatically happens. In v3 I've adjusted it to say "large inputs can
overflow these counters".
>
> > Unlike the previous patches, this is not specific to LLP64: "unsigned"
> > [...]
> > as needed.
>
> These paragraphs very much read like AI to me. I would appreciate a
> human touch, also to demonstrate that a human was involved between us
> and the AI that tries to understand what was done.
You're completely right. I used AI tooling to help draft that commit
message, and it definitely shows. Fair cop.
To clarify my involvement: I review the code, check the cases, run the
tests, and take full responsibility for what gets submitted. But the
wording here missed the mark. For v3 I rewrote the message myself,
keeping it much shorter, focusing on a single example (lone LFs), and
dropping the heavy-handed explanations.
>
> > Use size_t for all of them, and compute the size hint in
> > ident_to_worktree() with st_add() and st_mult(), so that it dies
> > instead of wrapping around.
>
> That's awfully specific.
Agreed, it spells out the implementation details which are already
obvious from the diff. In v3 I've simplified it to just state that the
size hint is checked for overflow.
>
> The patch itself looks good to me, thanks.
Thanks for the careful review! v3 will follow shortly in the same
thread.
Elia
next prev parent reply other threads:[~2026-10-31 10:16 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-21 10:16 [PATCH 0/3] use size_t for a few more object and buffer sizes Elia Pinto
2026-10-21 10:16 ` [PATCH 1/3] odb: use size_t for the length of objects to write Elia Pinto
2026-10-21 11:24 ` Patrick Steinhardt
2026-10-21 10:16 ` [PATCH 2/3] diff: use size_t for the allocation size of word-diff buffers Elia Pinto
2026-10-21 11:24 ` Patrick Steinhardt
2026-10-21 10:16 ` [PATCH 3/3] convert: use size_t for buffer sizes Elia Pinto
2026-10-21 11:24 ` Patrick Steinhardt
2026-10-30 9:58 ` [PATCH v2 0/4] use size_t for a few more object and " Elia Pinto
2026-10-30 9:58 ` [PATCH v2 1/4] odb: use size_t for the length of objects to write Elia Pinto
2026-10-30 11:44 ` Patrick Steinhardt
2026-10-31 10:16 ` Elia Pinto
2026-10-30 9:58 ` [PATCH v2 2/4] diff: use size_t for the allocation size of word-diff buffers Elia Pinto
2026-10-30 9:58 ` [PATCH v2 3/4] convert: use size_t for buffer sizes Elia Pinto
2026-10-30 9:58 ` [PATCH v2 4/4] convert: use size_t for text statistics and ident counts Elia Pinto
2026-10-30 11:44 ` Patrick Steinhardt
2026-10-31 10:16 ` Elia Pinto [this message]
2026-10-31 10:16 ` [PATCH v3 0/4] use size_t for a few more object and buffer sizes Elia Pinto
2026-10-31 10:16 ` [PATCH v3 1/4] odb: use size_t for the length of objects to write Elia Pinto
2026-10-31 10:16 ` [PATCH v3 2/4] diff: use size_t for the allocation size of word-diff buffers Elia Pinto
2026-10-31 10:16 ` [PATCH v3 3/4] convert: use size_t for buffer sizes Elia Pinto
2026-10-31 10:16 ` [PATCH v3 4/4] convert: use size_t for text statistics and ident counts Elia Pinto
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=20261031101619.172770-2-gitter.spiros@gmail.com \
--to=gitter.spiros@gmail.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
--cc=ps@pks.im \
/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