Re: 64 bit numbers vs format strings

On 15.03.25 03:42, Thomas Munro wrote:
>> - 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.

The ramifications of such a change are not clear to me.  I thought 
pgoff_t is supposed to be off_t on Unix systems.  If we change that, 
then how will this affect pointer type arguments, function pointers, 
etc.  This seems to be a much larger problem than what this thread is 
originally about.

I think we should leave pgoff_t the way it is (mostly?) done now: Cast 
to long long int and print using %lld.

> 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.

This is not really possible.  The <PRIxxx> behavior is baked deeply into 
the gettext code.  (Also note that you don't only need support in 
xgettext, which is part of our build system, but also in the runtime 
library, which we don't control.)