Re: PRI?64 vs Visual Studio (2022) - Mailing list pgsql-hackers

On Thu, Nov 20, 2025 at 4:44 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Peter Eisentraut <peter@eisentraut.org> writes:
> > On 19.11.25 04:15, Tom Lane wrote:
> >> I think we should do it
> >> honestly with a regression test.  It doesn't need to be very
> >> complicated --- I think checking one message in one translation is
> >> sufficient, so long as it includes a PRI?64 usage.
>
> > We could generate an English message catalog that translates all
> > messages unchanged, and run the whole test suite with that.  This would
> > exercise the whole gettext run-time machinery.
>
> ... except that if it were actually doing nothing whatsoever, you
> could not tell.  This seems particularly troublesome for gettext,
> since its fallback behavior is exactly to return the given string.
> I'd prefer a test that fails in a visible way.

How about a test module with a test_nls() function that just raises an
error containing "hello %" PRId64 ", ..." with all the macros we care
about, and regression test that calls it, and two alternative expected
files with "hello ...", "hola ...", matching en.po and es.po (or
choose some other second language that we think is likely to be tested
by a subset of BF animals and/or a CI task)?  Then if you didn't
enable -Dnls it'd still pass with English, and if you did it'd pass
for any language.  Since there are no other .po files, if you had some
third language it'd fall back to English, and the .po would have a "do
not translate" comment or even prefix in the message to avoid
confusing the translation team.  That assumes that modules are allowed
to supply .po files, I didn't check, if that's not true then maybe
it'd have to be in core instead.  That'd test quite a lot of moving
parts at once.

The reason I thought about a contrived message with lots of macros is
that I'd stumbled across a partial implementation[1] in Alpine's
alternative non-GNU msgfmt program, which appears to have PRIu64 but
not PRIx64 and others.  It also has some other way of encoding this
stuff in the .mo that musl's alternative built-in libintl
implementation can understand (it looks like they have arranged to be
able to mmap the .mo and use it directly as shared read-only memory,
while GNU's implementation has to allocate memory to translate them to
%lld etc in every process, clever but (I assume) broken if
msgfmt/libintl implementations are mixed), so I figured it'd be a good
idea to make sure that we test that all the macros actually work.  I
didn't try to understand the implications of Wolfgang's reply, but I
guess that to have any chance of Alpine's libintl pickle being
straightened out, we'd ideally want a test case that someone
interested in that could use to validate the whole localisation
pipeline conclusively.

[1]
https://www.postgresql.org/message-id/flat/CA%2BhUKG%2Bpp%3D%3Dd-3LVhdNOvOAzwQN0vP4gBSxtHkmxnmfQD3NY%3Dw%40mail.gmail.com#167da8f2fb3093bc0fa0a8335c054c19