Re: Use of PRId64 with PostgreSQL functions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Paragon Corporation" <lr(at)pcorp(dot)us>
Cc: alvherre(at)2ndquadrant(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Use of PRId64 with PostgreSQL functions
Date: 2015-07-31 23:43:05
Message-ID: 13415.1438386185@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Paragon Corporation" <lr(at)pcorp(dot)us> writes:
>> Huh. Apparently, whichever Windows compiler you're using defines
>> PRId64 as "d", which surely seems pretty broken.

> I think it was only failing on the postgresql function calls.

> And this: gcc -Wall -E testint.c | grep '\(printf.*x)\| int64_t;\)'
> Returned:
> __extension__ typedef long long int64_t;
> printf("%" "I64d", x);

Oooh ... so the issue is the nonstandard "I64" length modifier.
Now I understand. That probably works fine with Microsoft's printf,
but

(1) gcc does not understand it, which is why you're getting the compile
warnings with the erroneous claim that the format is just "d", and

(2) our implementation of snprintf doesn't understand it either, which
presumably is causing weird runtime behavior for you when you try to
use this with StringInfo functions.

Adherence to standards was never MS' strong point was it.

Anyway, it would be advisable to switch your declarations to use PG's
int64 if you are going to use INT64_FORMAT. If you use that macro with a
platform-provided int64_t declaration then you are going to get compile
warnings on some platforms; that is exactly the point that Andres was
making in the previous discussion.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2015-08-01 00:09:26 Re: patch: prevent user from setting wal_buffers over 2GB bytes
Previous Message Paragon Corporation 2015-07-31 22:34:45 Re: Use of PRId64 with PostgreSQL functions