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-15T17:05:38Z
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 Mon, Dec 15, 2025 at 8:01 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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?

> So close yet so far... I tried asking if it's easy to fix:

> https://github.com/sabotage-linux/gettext-tiny/issues/76

Hmm, not sure if you found the live upstream for that project, but if
you did, this code hasn't been touched since 2019.  Think we shouldn't
hold our breath for a fix :-(.  I will go add another expected-file.

I'm also thinking that maybe we should expand the ambition of that
test script a little.  Instead of only checking the behavior of PRI*
when we can test translation, why not run the ereport's all the time?
This would at least test that <inttypes.h> is sane and snprintf.c
agrees with it, which we now know is something worth checking.  That's
colored by seeing that less than half of the buildfarm is finding any
variant of es_ES to test in.  That's not great, but I'm not seeing
anything to be done about it.  The only locale names we can be sure
will be accepted are C/POSIX, and I'd expect gettext() to
short-circuit that case and not look for a translation.  I'm thinking
though that it's still worth checking that the untranslated string is
processed correctly.

			regards, tom lane