Re: [HACKERS] [COMMITTERS] pgsql: Fix compiler warnings on 64-bit boxes:

[Tom Lane]

Gavin Sherry [EMAIL PROTECTED] writes:
 It might seem a minor quibble, but it seems like a more reliable approach
 might be to cast to a 64 bit type and user a 64 bit int formatter.

int64 is a real pain to use in error messages because of the
machine-dependence of the format string --- the translation machinery
doesn't work reliably if you try to do

ereport(...errmsg(trouble at offset  UINT64_FORMAT, bigintvar));

because any given translator will see only one of the several possible
source strings.  You can get around this if you have to (print the
bigint into a char[n] local array and then use %s in the message),
but it's not worth it when dealing with values that can't plausibly
overflow an int.  I think Teodor fixed it the right way.

regards, tom lane

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] [COMMITTERS] pgsql: Fix compiler warnings on 64-bit boxes:

[Tom Lane]

Teodor Sigaev [EMAIL PROTECTED] writes:
 ereport(...errmsg(trouble at offset  UINT64_FORMAT, bigintvar));

 One more solution: add format code %D to expand_fmt_string() which should be 
 expanded to usual %d on 32-bit architecture and to UINT64_FORMAT on 64-bit.

Not very workable unless you can figure out how to teach gcc what it means...
else we lose compiler checking that the corresponding argument matches,
which'd be even more important than usual with a machine-dependent
format code.

regards, tom lane

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings