The `%I64` printf format family is a Windows-specific extension that has
been handled for, like, eternity in `mingw-w64-gettext`. But the recent
update to v0.22.3 broke that.
The reason for that is a story of two episodes:
- gnulib slipped in a major refactoring of the `printf()` format parsing
into a commit whose purpose was to support new size specifiers:
https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=480a59ba60fa0b43a1cebe218bbcea6a947f1e86
Unfortunately, the code handling `%I64` was converted incorrectly,
where it previously skipped the `64` part before looking for the
conversion specifier (correct) but now no longer does so (incorrect):
https://git.savannah.gnu.org/cgit/gnulib.git/diff/lib/printf-parse.c?id=480a59ba60fa0b43a1cebe218bbcea6a947f1e86
- gettext saw a major refactoring with the intention to avoid
duplicating gnulib's `printf()` logic, dropping its own code in favor
of the latter:
https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=commitdiff;h=a80b9021019fe311b81771d67138496f512ef35a
The result is that as of `mingw-w64-gettext` v0.22.3, `%I64d` is
_started_ to be parsed but then fails because it mistakes `6` for the
conversion character (instead of recognizing `d` as such).
Work around this regression by skipping the `64` part again.
This patch needs to be upstreamed to the gnulib project, yet we need to
fix the `mingw-w64-gettext` regression at a more timely pace and need to
integrate the patch early.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
jsonnet-0.20.0/third_party/rapidyaml/rapidyaml/ext/c4core/src/c4/ext/./fast_float/include/fast_float/float_common.h:165:17: error: use of undeclared identifier '__umulh'
