Git development
 help / color / mirror / Atom feed
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.

      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