Re: PRI?64 vs Visual Studio (2022)

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