]> git.99rst.org Git - git.git/commit
submodule--helper: avoid use of %zu for now
authorJunio C Hamano <redacted>
Wed, 15 Jul 2026 20:10:06 +0000 (13:10 -0700)
committerJunio C Hamano <redacted>
Wed, 15 Jul 2026 20:13:20 +0000 (13:13 -0700)
commit3279c13c00f0d9c4ba7d2b67c73c36ec308e5366
treeb7370683f598df1b567f5affc26beb76b74c0b60
parent94f057755b7941b321fd11fec1b2e3ca5313a4e0
submodule--helper: avoid use of %zu for now

Since d7d850e2b9 (CodingGuidelines: mention C99 features we can't
use, 2022-10-10), our CodingGuidelines document has explicitly
forbidden the use of '%z' and '%zu' printf() format specifiers,
even though C99 does support them.  However, a new instance crept
in via 82c36fa0a9 (submodule: hash the submodule name for the
gitdir path, 2026-01-12).

We could claim that this is an unintentional weather balloon that
nobody has complained about for the past six months since Git 2.54,
proving that it is now safe to use these format specifiers.  But
(1) it is probably too early to make that claim, as distributions
often stick to a stale version for several releases, and (2) it is
unlikely that a failure in this code path would manifest as a
major user-visible breakage that would trigger a failure report to
percolate down to us.

Instead, let's stick to the established workaround recommended by
our CodingGuidelines, which is to cast the value to (uintmax_t) and
format it with PRIuMAX, at least for now.  Even if we eventually
perform a bulk update using a Coccinelle script to transition to %z
and %zu in the future, adding one more instance to the pile that
will need such a conversion is hardly a tragedy.

Signed-off-by: Junio C Hamano <redacted>
builtin/submodule--helper.c
git clone https://git.99rst.org/PROJECT