Re: A couple of cosmetic changes around shared memory code

Поиск
Список
Период
Сортировка
От Piotr Stefaniak
Тема Re: A couple of cosmetic changes around shared memory code
Дата
Msg-id BLU436-SMTP4434E1C649EDEF56079FAFF24A0@phx.gbl
обсуждение исходный текст
Ответ на Re: A couple of cosmetic changes around shared memory code  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 2016-05-17 19:05, Tom Lane wrote:
> Michael Paquier <michael.paquier@gmail.com> writes:
>> On Tue, May 17, 2016 at 4:40 AM, Piotr Stefaniak
>> <postgres@piotr-stefaniak.me> wrote:
>> -    toc_bytes = offsetof(shm_toc, toc_entry) +nentry * sizeof(shm_toc_entry)
>> +    toc_bytes = offsetof(shm_toc, toc_entry) + nentry * sizeof(shm_toc_entry)
>>          + allocated_bytes;
>
>> I don't recall the exact reason, but this is intentional style
>> (memories from a patchwork with Tom).
>
> Well, it's not so much intentional as that pgindent will make it look like
> that no matter what you do --- it's got some weird interaction with
> sizeof, offsetof, and typedef names versus operators later on the same
> line.  I'd call that a pgindent bug myself, but have no particular desire
> to try to fix it.
From my understanding, it's because pg_bsd_indent thinks that 
"(shm_toc)" is a cast since shm_toc is a keyword (type alias fetched 
from the "list of typedefs" file in this case, to be precise), forcing 
the "+" to be a unary operator instead of binary.

One easy way to work around this bug is putting shm_toc into its own 
parentheses but I'd prefer dropping this particular fix from my 
"cosmetic changes" patch until pg_bsd_indent is fixed.

I may come up with a possible fix for this bug, but don't hold your breath.



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

Предыдущее
От: Craig Ringer
Дата:
Сообщение: Re: foreign table batch inserts
Следующее
От: "Tsunakawa, Takayuki"
Дата:
Сообщение: Re: foreign table batch inserts