Horton

Re: PRI?64 vs Visual Studio (2022)

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Peter Eisentraut <peter@eisentraut.org>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, walther@technowledgy.de, pgsql-hackers@lists.postgresql.org
Date: 2025-12-15T07:01:52Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Test PRI* macros even when we can't test NLS translation.

  2. Avoid requiring Spanish locale to test NLS infrastructure.

  3. Drop support for MSVCRT's float formatting quirk.

  4. Drop support for MSVCRT's %I64 format strings.

  5. Use PRI?64 instead of "ll?" in format strings (continued).

  6. Use <stdint.h> and <inttypes.h> for c.h integers.

  7. Make float exponent output on Windows look the same as elsewhere.

Thomas Munro <thomas.munro@gmail.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