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

Log Message:
-----------
Fix compiler warnings on 64-bit boxes: difference between
pointers are int64, but warnings are emitted for position info in
error messages in parser, so, just cast it to int32

Modified Files:
--------------
pgsql/contrib/hstore:
hstore_io.c (r1.1 -> r1.2)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/contrib/hstore/hstore_io.c.diff?r1=1.1&r2=1.2)

On Wed, 6 Sep 2006, Teodor Sigaev wrote:

> Log Message:
> -----------
> Fix compiler warnings on 64-bit boxes: difference between
> pointers are int64, but warnings are emitted for position info in
> error messages in parser, so, just cast it to int32
>
> Modified Files:
> --------------
> pgsql/contrib/hstore:
> hstore_io.c (r1.1 -> r1.2)
> (http://developer.postgresql.org/cvsweb.cgi/pgsql/contrib/hstore/hstore_io.c.diff?r1=1.1&r2=1.2)

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.

It seems unlikely that state->ptr - state->begin would yield a number that
large but I don't know that that would be true of every platform or user.

Thanks,

Gavin

> 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.
%ld ? %lld? depending on architecture?

>
> It seems unlikely that state->ptr - state->begin would yield a number that
> large but I don't know that that would be true of every platform or user.

I don't believe that it can be more that 1Gb - it's a limit for any varlena type.

--
Teodor Sigaev E-mail: teodor(at)sigaev(dot)ru
WWW: http://www.sigaev.ru/

On Wed, 6 Sep 2006, Teodor Sigaev wrote:

> > 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.
> %ld ? %lld? depending on architecture?
>
> >
> > It seems unlikely that state->ptr - state->begin would yield a number that
> > large but I don't know that that would be true of every platform or user.
>
> I don't believe that it can be more that 1Gb - it's a limit for any varlena type.
>

True. int32 should be fine.

Thanks,

gavin

Gavin Sherry <swm(at)linuxworld(dot)com(dot)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(at)sigaev(dot)ru
WWW: http://www.sigaev.ru/

Teodor Sigaev <teodor(at)sigaev(dot)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