Re: shared memory message queues

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: shared memory message queues
Дата
Msg-id 28340.1389807568@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: shared memory message queues  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: shared memory message queues  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Jan 14, 2014 at 9:28 PM, Peter Eisentraut <peter_e@gmx.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Claudio Freire
Дата:
Сообщение: Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Changeset Extraction v7.0 (was logical changeset generation)