From: Junio C Hamano <gitster@pobox.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: git@vger.kernel.org,
Oswald Buddenhagen <oswald.buddenhagen@gmx.de>,
Taylor Blau <me@ttaylorr.com>, Jeff King <peff@peff.net>
Subject: Re: [PATCH] git-compat-util: introduce `count_t` typedef
Date: Thu, 07 Aug 2025 09:38:46 -0700 [thread overview]
Message-ID: <xmqqa54bqe7d.fsf@gitster.g> (raw)
In-Reply-To: <20250807-pks-introduce-count-t-v1-1-e96be52d8db1@pks.im> (Patrick Steinhardt's message of "Thu, 07 Aug 2025 11:22:56 +0200")
Patrick Steinhardt <ps@pks.im> writes:
> For C programs:
>
> + - We use `size_t` to count the number of bytes and `count_t` to count the
> + number of entities of a given type.
I am not interested in this specific implementation at all for a
number of reasons, but I am excited to see people thinking about the
issues. The following is a random list of things, both positive and
negative, that came to my mind after skimming the changes.
* We do not want to pretend that one size fits all. If it were a
good idea for developers to express "This variable is a simple
counter that counts up from 0 and never goes negative" by using
an unsigned type (which is dubious), it should be equally, or not
more, a good idea to allow them to say "We will not have more
than 256 fan-out directories under .git/objects/ and this is a
counter to count them, so I know 'unsigned short' is big enough
on any platforms".
* As far as I can tell, the patch does not seem to address the
biggest concern of unsigned integer wraparound. We often see
ALLOC_GROW(thing.entry, thing.nr + 1, thing.alloc);
with the arithmetic "thing.nr + 1" checked by nobody.
ALLOC_GROW_BY() is slightly better in this regard, but nobody
uses it with only small exceptions. And of course, alloc_nr()
does even riskier arithmetic that is unchecked.
* Standardising the names used for <item[], item_nr, item_alloc>
somehow is very much welcome (we can see an example in the change
to builtin/rm.c below). Such a naming convention would allow us
to write
#define ALLOC_INCR(thing) ALLOC_INCR_BY(thing, 1)
ALLOC_INCR_BY(thing, increment)
that do ALLOC_GROW(thing, thing_nr + increment, thing_alloc) more
safely than what the current code does, perhaps? Also, we should
be able to use any unsigned integral type and perform sensible
bound checking with typeof().
* The codebase avoids inventing a new type with typedef, with the
exception of callback function type, following old tradition we
inherited from the Linux kernel project. And even when we create
a new type, of course, we do not want to give it a name that ends
with "_t".
> diff --git a/builtin/rm.c b/builtin/rm.c
> index 05d89e98c3..99b845cf34 100644
> --- a/builtin/rm.c
> +++ b/builtin/rm.c
> @@ -33,11 +33,11 @@ static const char * const builtin_rm_usage[] = {
> };
>
> static struct {
> - int nr, alloc;
> struct {
> const char *name;
> char is_submodule;
> } *entry;
> + count_t entry_nr, entry_alloc;
> } list;
next prev parent reply other threads:[~2025-08-07 16:38 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-07 9:22 [PATCH] git-compat-util: introduce `count_t` typedef Patrick Steinhardt
2025-08-07 11:00 ` Matthias Aßhauer
2025-08-07 14:17 ` Phillip Wood
2025-08-07 16:43 ` Junio C Hamano
2025-08-07 16:38 ` Junio C Hamano [this message]
2025-08-07 22:07 ` Taylor Blau
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=xmqqa54bqe7d.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=me@ttaylorr.com \
--cc=oswald.buddenhagen@gmx.de \
--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 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.