Re: 64 bit numbers vs format strings

On Mon, Mar 10, 2025 at 10:49 PM Peter Eisentraut <peter(at)eisentraut(dot)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...)