Re: pgindent && weirdness - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: pgindent && weirdness
Date
Msg-id CA+hUKGKwQ85a_YH81p_TBtf-fLLTduFcTPERniDpQ55kXdnvhA@mail.gmail.com
Whole thread Raw
In response to Re: pgindent && weirdness  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pgindent && weirdness
Re: pgindent && weirdness
List pgsql-hackers
On Tue, Feb 18, 2020 at 12:42 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Thomas Munro <thomas.munro@gmail.com> writes:
> > Another problem is that there is one thing in our tree that looks like
> > a non-cast under the new rule, but it actually expands to a type name,
> > so now we get that wrong!  (I mean, unpatched indent doesn't really
> > understand it either, it thinks it's a cast, but at least it knows the
> > following * is not a binary operator):
>
> > -       STACK_OF(X509_NAME) *root_cert_list = NULL;
> > +       STACK_OF(X509_NAME) * root_cert_list = NULL;
>
> > That's a macro from an OpenSSL header.  Not sure what to do about that.
>
> If we get that wrong, but a hundred other places look better,
> I'm not too fussed about it.

Here's the patch I propose to commit to pg_bsd_indent, if the repo
lets me, and here's the result of running it on the PG tree today.

I suppose the principled way to fix that problem with STACK_OF(x)
would be to have a user-supplied list of function-like-macros that
expand to a type name, but I'm not planning to waste time on that.

Attachment

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Multiple FPI_FOR_HINT for the same block during killing btreeindex items
Next
From: Tom Lane
Date:
Subject: Re: pgindent && weirdness