From: Junio C Hamano <gitster@pobox.com>
To: Paulius Zaleckas <paulius.zaleckas@gmail.com>
Cc: git@vger.kernel.org, "Ramsay Jones" <ramsay@ramsayjones.plus.com>,
"Jean-Noël Avila" <avila.jn@gmail.com>,
"Glen Choo" <glencbz@gmail.com>, "Patrick Steinhardt" <ps@pks.im>,
"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Subject: Re: [PATCH v5 2/2] fetch: add fetch.submoduleErrors to make submodule fetch errors non-fatal
Date: Wed, 15 Jul 2026 12:13:45 -0700 [thread overview]
Message-ID: <xmqq7bmwm5g6.fsf@gitster.g> (raw)
In-Reply-To: <20260715103518.526326-3-paulius.zaleckas@gmail.com> (Paulius Zaleckas's message of "Wed, 15 Jul 2026 13:35:16 +0300")
Paulius Zaleckas <paulius.zaleckas@gmail.com> writes:
> +/* really private - use accessors below to parse and format */
> +static const char *submodule_errors_names[] = {
> + [SUBMODULE_ERRORS_FAIL] = "fail",
> + [SUBMODULE_ERRORS_WARN] = "warn",
> +};
> +
> +static const char *submodule_errors_to_string(int mode)
> +{
> + if (mode < 0 || (size_t)mode >= ARRAY_SIZE(submodule_errors_names))
> + BUG("invalid submodule errors mode %d", mode);
> + return submodule_errors_names[mode];
> +}
> +
I am ranting here, and it is not entirely your fault, but I
have to mention that this is the kind of bad code that
"-Wsign-compare" forces on us. We know that 'mode' is a small
integer used to index into the submodule_errors_names[] array.
Theoretically, an array might contain as many elements as
(size_t)(-1), but we know nobody needs to feed us a number
that does not fit in a platform-natural "int".
Side note: submodule_errors_names[] is a horrible name.
It should be submodule_error_name[]. Look for "Array names"
in the CodingGuidelines document.
Working around "-Wsign-compare" has forced an unnecessary cast on
us here. If anything, we could have just done:
static const char *submodule_errors_to_string(unsigned mode)
and
if (ARRAY_SIZE(submodule_error_names) <= mode)
BUG(...);
which would have been vastly more readable. To me, a plain "int"
is also fine, but if we must squelch "-Wsign-compare", using
"unsigned" is much saner than turning everything into "size_t".
> +static int parse_submodule_errors(const char *name)
> +{
> + size_t i;
> +
> + for (i = 0; i < ARRAY_SIZE(submodule_errors_names); i++)
> + if (!strcmp(submodule_errors_names[i], name))
> + return i;
> + return -1;
> +}
And there is no sensible way to justify "size_t i" here. Using
a platform-natural "unsigned" would have been much easier to
understand.
It is a disease to bend our code only to appease the compiler's
warnings; we should resist such temptation.
Also worth reading:
https://staticthinking.wordpress.com/2023/07/25/wsign-compare-is-garbage/
Thanks.
prev parent reply other threads:[~2026-07-15 19:13 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-10 12:26 [PATCH v3 0/2] fetch: make submodule fetch errors configurable Paulius Zaleckas
2026-07-10 12:26 ` [PATCH v3 1/2] submodule: fix premature failure in recursive submodule fetch Paulius Zaleckas
2026-07-10 12:26 ` [PATCH v3 2/2] fetch: add fetch.submoduleErrors to make submodule fetch errors non-fatal Paulius Zaleckas
2026-07-10 22:21 ` Junio C Hamano
2026-07-14 13:29 ` Paulius Zaleckas
2026-07-14 13:29 ` [PATCH v4 0/2] fetch: make submodule fetch errors configurable Paulius Zaleckas
2026-07-14 13:29 ` [PATCH v4 1/2] submodule: fix premature failure in recursive submodule fetch Paulius Zaleckas
2026-07-14 13:29 ` [PATCH v4 2/2] fetch: add fetch.submoduleErrors to make submodule fetch errors non-fatal Paulius Zaleckas
2026-07-14 15:34 ` Junio C Hamano
2026-07-14 17:14 ` Junio C Hamano
2026-07-15 10:35 ` [PATCH v5 0/2] fetch: make submodule fetch errors configurable Paulius Zaleckas
2026-07-15 10:35 ` [PATCH v5 1/2] submodule: fix premature failure in recursive submodule fetch Paulius Zaleckas
2026-07-15 10:35 ` [PATCH v5 2/2] fetch: add fetch.submoduleErrors to make submodule fetch errors non-fatal Paulius Zaleckas
2026-07-15 19:13 ` Junio C Hamano [this message]
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=xmqq7bmwm5g6.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=avarab@gmail.com \
--cc=avila.jn@gmail.com \
--cc=git@vger.kernel.org \
--cc=glencbz@gmail.com \
--cc=paulius.zaleckas@gmail.com \
--cc=ps@pks.im \
--cc=ramsay@ramsayjones.plus.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