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-15T20:19:26Z
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:
> On Tue, Dec 16, 2025 at 8:29 AM Peter Eisentraut <peter@eisentraut.org> wrote:
>> I think that means that that gettext implementation is not currently
>> supportable.  So either we revert our PRI* use except those two
>> (unlikely), or those buildfarm members should disable NLS.

> Yeah.  My goal in mentioning the problem back when it was just a
> problem in theory (we had no test, the Alpine packages disable nls
> (perhaps it used to be *more* broken, if they did that before we used
> PRI?)) was to try to see if someone closer to these musl distros
> wanted to have a crack at fixing it, since it looks pretty close to
> being usable.  But now that it's a problem in practice, it's hard to
> disagree with Peter's take.  It could be reenabled any time it works
> enough to pass the test.

Fair enough.  I've revised the test mechanism per discussion with
Bryan Green, in hopes of being able to test on more BF animals than
we could yesterday.  But I won't put in an expected-file for this
Alpine misbehavior.

			regards, tom lane