Re: PRI?64 vs Visual Studio (2022)
Tom Lane <tgl@sss.pgh.pa.us>
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>,
pgsql-hackers@lists.postgresql.org
Date: 2025-11-19T03:15:54Z
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 →
-
Test PRI* macros even when we can't test NLS translation.
- 462e2476525e 19 (unreleased) landed
-
Avoid requiring Spanish locale to test NLS infrastructure.
- 7db6809ced44 19 (unreleased) landed
-
Drop support for MSVCRT's float formatting quirk.
- 6b46669883fa 19 (unreleased) landed
-
Drop support for MSVCRT's %I64 format strings.
- 7ab9b34614c2 19 (unreleased) landed
-
Use PRI?64 instead of "ll?" in format strings (continued).
- a0ed19e0a9ef 18.0 cited
-
Use <stdint.h> and <inttypes.h> for c.h integers.
- 962da900ac8f 18.0 cited
-
Make float exponent output on Windows look the same as elsewhere.
- f1885386f624 12.0 cited
Thomas Munro <thomas.munro@gmail.com> writes: > Perhaps meson/configure should do a po -> mo -> gettext() check with a > canned test message? That'd also make sure your msgfmt and libintl > are compatible, something I worried about when I wrote about musl > recently. No, I don't think that's a good approach. That is testing the library available at configure time, not the one you are actually running with (possibly years later and on a different machine, even without considering cross-compilation cases). 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. regards, tom lane