Re: PRI?64 vs Visual Studio (2022)

Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> 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.

So now we have that, and sure enough our two Alpine buildfarm members
are failing like this [1][2]:

diff -U3 /mnt/build/HEAD/pgsql/src/test/regress/expected/nls_1.out /mnt/build/HEAD/pgsql.build/testrun/regress/regress/results/nls.out
--- /mnt/build/HEAD/pgsql/src/test/regress/expected/nls_1.out
+++ /mnt/build/HEAD/pgsql.build/testrun/regress/regress/results/nls.out
@@ -34,7 +34,22 @@
\\quit
\\endif
SELECT test_translation();
-NOTICE: NLS is not enabled
+NOTICE: translated PRId64 = 424242424242
+NOTICE: translated PRId32 = -1234
+NOTICE: translated PRIdMAX = -5678
+NOTICE: translated PRIdPTR = 9999
+NOTICE: traducido PRIu64 = 424242424242
+NOTICE: traducido PRIu32 = 1234
+NOTICE: translated PRIuMAX = 5678
+NOTICE: translated PRIuPTR = 9999
+NOTICE: translated PRIx64 = 62c6d1a9b2
+NOTICE: translated PRIx32 = 4d2
+NOTICE: translated PRIxMAX = 162e
+NOTICE: translated PRIxPTR = 270f
+NOTICE: translated PRIX64 = 62C6D1A9B2
+NOTICE: translated PRIX32 = 4D2
+NOTICE: translated PRIXMAX = 162E
+NOTICE: translated PRIXPTR = 270F
test_translation
------------------

So their gettext handles PRIu64 and PRIu32 and nothing else.

What to do now? I could revert 8c498479d and followups, but
I sure don't want to. A stopgap measure to make the farm look
green would be to add a variant expected-file that accepts
this output, but yech. Thoughts?

regards, tom lane

[1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=basilisk&dt=2025-12-15%2004%3A35%3A44
[2] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=dogfish&dt=2025-12-15%2005%3A19%3A50