On 2015-05-26 20:25:24 -0400, Peter Eisentraut wrote:
> On 5/25/15 7:15 PM, Andres Freund wrote:
> > On 2015-05-25 19:01:28 -0400, Bruce Momjian wrote:
> >>> A longer-term fix would be to make pgindent less stupid about this sort
> >>> of usage, but nobody's yet volunteered to dig into the guts of that code.
> >>
> >> I assume a typedefs list is going to be a requirement of any decent C
> >> indenting tool.
> >
> > Maybe I'm missing something major here, but why? Afaict it's just only
> > used for formatting decisions that could be made without it just as well?
>
> AFAICT, the main reason is to decide whether * and & are binary infix or
> unary prefix operators. Otherwise, it wouldn't know whether to write
>
> char * foo;
>
> or the more customary
>
> char *foo;
>
> Now, running pgindent without a typedefs list also makes it do things like
>
> static int32
> -makepol(QPRS_STATE *state)
> +makepol(QPRS_STATE * state)
>
> which, one might argue, it could figure out without a typedefs list.
> But then the formatting would be inconsistent between prototypes and
> variable declarations, which might drive people crazy. I don't know
> whether there is a better way than living with it, one way or the other
> (i.e., requiring a types list, or accepting slightly odd formatting).
I actually think both are relatively easy to figure out without a
typedef list. There's harder cases though, e.g. (char *) &foo in an
expression is already more complicated.
But really, the typedef list is the minor part what annoys me about
pgindent. That it completely butchers so many constructs (e.g. function
pointer typedefs, inline asm as extreme examples) is much worse. It's
also neigh on impossible to predict/keep the indentation pgindent will
use in many cases. Having to try to write code in a way that doesn't
break the re-indentation tool, even if it'd otherwise be fine, is just
absurd.
Greetings,
Andres Freund