From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, Andres Freund <andres(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: shared memory message queues |
Date: | 2014-01-15 17:39:28 |
Message-ID: | 28340.1389807568@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Jan 14, 2014 at 9:28 PM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
>> Something is causing this new compiler warning:
>>
>> setup.c: In function setup_dynamic_shared_memory:
>> setup.c:102:3: error: format %llu expects argument of type long long unsigned int, but argument 2 has type Size [-Werror=format=]
> Oops. I've pushed a fix (at least, I hope it's a fix).
Unless I'm misreading what you did, that will just move the problem to
a different set of platforms. size_t is not necessarily "long" (one
counterexample is Win64, IIRC).
In the past we've usually resorted to explicitly casting. You could
silence the warning correctly with either of
ereport("... %lu ...", (unsigned long) shm_mq_minimum_size);
ereport("... " UINT64_FORMAT " ...", (uint64) shm_mq_minimum_size);
However, the problem with the second one (which also existed in your
original code) is that it breaks translatability of the string, because
any given translator is only going to see the version that gets compiled
on their hardware. Unless there's a significant likelihood of
shm_mq_minimum_size exceeding 4GB, I'd go with the first one.
If you really want to be able to print values >4GB in translatable
messages, what you need to do is to print into a local string variable
with UINT64_FORMAT, then use %s in the translatable string. There's
examples of this in commands/sequence.c among other places.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2014-01-15 17:43:04 | Re: Changeset Extraction v7.0 (was logical changeset generation) |
Previous Message | Claudio Freire | 2014-01-15 17:06:00 | Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance |