Re: [COMMITTERS] pgsql: Centralize definition of integer limits.

On 2015-03-30 15:38:16 -0400, Tom Lane wrote:
> Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
> > On Mon, Mar 30, 2015 at 7:48 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> >> On 2015-03-30 14:01:25 +0900, Michael Paquier wrote:
> >>> My OSX dev box is generating a couple of warnings since this commit:
> >>> pg_dump.c:14548:45: warning: format specifies type 'long' but the
> >>> argument has type 'long long' [-Wformat]
>
> FWIW, I'm seeing the same thing on my OSX laptop. I think the explanation
> is simple: both "long" and "long long" are 64 bits on this machine.
> Our configure chooses the former to be "int64", but stdint.h is using
> the latter. I'm not sure there's any good way to know what stdint.h
> thinks is int64, but we can't do a half-baked integration job like this.
> Either we revert 83ff1618b altogether, or we make int64/uint64 depend
> on definitions from stdint.h rather than being chosen independently by
> configure.

Obviously we need to fix this, but I'd actually say this isn't
originally the fault of that change. The disparity in types already
existed in a bunch of places (timestamp.c, pgbench.c), now it's more
central, that's all.

I'm too fried from the redeye back from pgconf nyc to do anything
complicated, but it seems quite possible to define int64/uint64 based
the stdint.h types if available. And generally a good idea too. I guess
I'll try that tomorrow; unless Andrew beats me to it.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services