Re: PRI?64 vs Visual Studio (2022)

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: PRI?64 vs Visual Studio (2022)
Date: 2025-11-19 09:19:47
Message-ID: e7b902aa-98ac-4d35-bae3-d7d282a938c2@eisentraut.org
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 19.11.25 04:15, Tom Lane wrote:
> Thomas Munro <thomas(dot)munro(at)gmail(dot)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.

We could generate an English message catalog that translates all
messages unchanged, and run the whole test suite with that. This would
exercise the whole gettext run-time machinery.

Generating the message catalog is easy, gettext provides a tool for
that. What's a little tricky is convincing all our testing
infrastructure to *not* disable NLS-related locale settings. See
attached for a rough, incomplete demo.

Attachment Content-Type Size
0001-Create-English-message-catalog-for-testing.patch text/plain 2.8 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Chao Li 2025-11-19 09:19:57 Re: gen_guc_tables.pl: Validate required GUC fields before code generation
Previous Message BharatDB 2025-11-19 09:08:37 Re: BUG #19095: Test if function exit() is used fail when linked static