Re: A couple of cosmetic changes around shared memory code

From: Piotr Stefaniak <postgres(at)piotr-stefaniak(dot)me>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: A couple of cosmetic changes around shared memory code
Date: 2016-05-19 05:48:04
Message-ID: BLU436-SMTP4434E1C649EDEF56079FAFF24A0@phx.gbl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2016-05-17 19:05, Tom Lane wrote:
> Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
>> On Tue, May 17, 2016 at 4:40 AM, Piotr Stefaniak
>> <postgres(at)piotr-stefaniak(dot)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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tsunakawa, Takayuki 2016-05-19 06:08:29 Re: foreign table batch inserts
Previous Message Craig Ringer 2016-05-19 05:38:48 Re: foreign table batch inserts