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