On Mon, Mar 10, 2025 at 10:49 PM Peter Eisentraut <pe...@eisentraut.org> wrote: > On 02.03.25 22:08, Thomas Munro wrote: > > Good plan, thanks. Here's a rebase. > > I think this went ok, and we can proceed here.
Cool, I'll post a new patch soon, but first a question about this bit: > - I don't think it's proper to assume that pgoff_t or off_t matches int64_t. So we should make pgoff_t a typedef for int64_t everywhere. It's a bit annoying that we have to teach everyone to remember to use PRId64 to print it, though. How reasonable would it be to add an extra filter into whatever script is used to run xgettext on our source tree? It could replace a very small number of agreed useful tokens to match some macros that we would also define in our tree, so that we could write PRI_PGOFF_T in our messages, but xgettext would see PRId64 and still emit those magic %<PRId64> tokens that GNU/NetBSD/Solaris gettext() know how to translate on the fly when loading message catalogues. I'm not sure how many other candidates there would be, not many (and LSN is obviously an attractive but thorny one...). (For those who missed the reason why: I believe xgettext only treats the <inttypes.h> macros with special portability gloves when used directly, so if you wrapped them in your own macros and did nothing else, you'd get the fully expanded macros as defined on the system that runs xgettext. if I understood correctly. Concretely, if that's a 64 bit glibc system where PRId64 is "ld", the resulting catalogues wouldn't work on a Windows or 32 bit system where sizeof(long) < sizeof(int64_t). You might be able to get away with it if you hijacked those macros as seen by xgettext and made them all "lld" everywhere since that's at least the right size on all known systems, but that'd be a bit gross and not in the spirit of this exercise...)
