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

Gavin Sherry <swm@linuxworld.com.au> 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

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

--
Teodor Sigaev                                   E-mail: teodor@sigaev.ru
                                                    WWW: http://www.sigaev.ru/

Teodor Sigaev <teodor@sigaev.ru> 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