All of lore.kernel.org
 help / color / mirror / Atom feed
From: Taylor Blau <me@ttaylorr.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Torsten Bögershausen" <tboegi@web.de>,
	"Chandra Pratap via GitGitGadget" <gitgitgadget@gmail.com>,
	git@vger.kernel.org,
	"Chandra Pratap" <chandrapratap376@gmail.com>,
	"Chandra Pratap" <chandrapratap3519@gmail.com>
Subject: Re: [PATCH] sideband.c: replace int with size_t for clarity
Date: Tue, 2 Jan 2024 17:31:18 -0500	[thread overview]
Message-ID: <ZZSOtiZSPSthcDgp@nand.local> (raw)
In-Reply-To: <xmqqedfejc32.fsf@gitster.g>

On Fri, Dec 22, 2023 at 11:01:37AM -0800, Junio C Hamano wrote:
> Torsten Bögershausen <tboegi@web.de> writes:
>
> Just this part.
>
> > Further down, we read
> > 	for (i = 0; i < ARRAY_SIZE(keywords); i++) {
> >
> > However, a size of an array can never be negative, so that
> > an unsigned data type is a better choice than a signed.
> > And, arrays can have more elements than an int can address,
> > at least in theory.
> > For a reader it makes more sense, to replace
> > int i;
> > with
> > size_t i;
>
> It is a very good discipline to use size_t to index into an array
> whose size is externally controled (e.g., we slurp what the end user
> or the server on the other end of the connection gave us into a
> piece of memory we allocate) to avoid integer overflows as "int" is
> often narrower than "size_t".  But this particular one is a Meh; the
> keywords[] is a small hardcoded array whose size and contents are
> totally under our control.

I certainly agree in theory, though I've always erred on the side of
always using size_t for indexing into arrays, even if they're small. It
removes a potential pitfall if you are working with an
externally-controlled array and happen to forget to use size_t.

But if there is an existing index variable with type "int", and we can
easily validate that it's small, I probably wouldn't bother changing it
if I was editing nearby code.

Thanks,
Taylor

  reply	other threads:[~2024-01-02 22:31 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-22 17:01 [PATCH] sideband.c: replace int with size_t for clarity Chandra Pratap via GitGitGadget
2023-12-22 17:57 ` Torsten Bögershausen
2023-12-22 18:27   ` Chandra Pratap
2023-12-22 18:39     ` Torsten Bögershausen
2023-12-22 19:01   ` Junio C Hamano
2024-01-02 22:31     ` Taylor Blau [this message]
2023-12-23 17:03 ` [PATCH v2] " Chandra Pratap via GitGitGadget
2023-12-27 10:20   ` [PATCH v3] sideband.c: remove redundant 'NEEDSWORK' tag Chandra Pratap via GitGitGadget
2023-12-27 22:22     ` Junio C Hamano
2023-12-28  8:01     ` [PATCH v4] " Chandra Pratap via GitGitGadget
2023-12-28 20:33       ` Junio C Hamano
2023-12-26 17:14 ` [PATCH] sideband.c: replace int with size_t for clarity Junio C Hamano

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=ZZSOtiZSPSthcDgp@nand.local \
    --to=me@ttaylorr.com \
    --cc=chandrapratap3519@gmail.com \
    --cc=chandrapratap376@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=gitster@pobox.com \
    --cc=tboegi@web.de \
    /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.