I wrote: >>> A small problem with the "rejiggering" is that it now makes the wrong >>> choice for K&R-style function definitions, causing them to be weirdly >>> indented. For our purposes, that's a non-problem so I'm not excited >>> about trying to make it smart enough to recognize those. We do have >>> a couple of amazingly old and crufty K&R-style functions in src/port/, >>> though, so probably we'd wish to fix those.
To be concrete about that: the existing behavior when trying to decide whether "foo(" starts a function declaration or a function definition is to scan to the matching right paren[1] and then, if the immediately next character is ';' or ',', it's a declaration; else it's a definition. This fails on decls with attributes, such as extern void pg_re_throw(void) __attribute__((noreturn)); My patch changes the rule to be "scan until we see a ';' ',' or '{' that's not within parens; then it's a definition if that character is '{', otherwise a declaration". So it gets the right answer for the above, but the wrong answer for int isinf(x) double x; { It doesn't really seem practical to me to make the lookahead function smart enough to tell the difference between attributes and K&R-style parameter declarations. What I'm thinking of doing to have an upstreamable patch is to invent a new switch, perhaps '-kr'/'-nkr', to indicate whether the user is more worried about K&R function declarations than she is about function attributes. The default for this switch could be debated perhaps, but I'd just stick an explicit -nkr into pgindent's invocation, so we wouldn't care too much. (This would also ensure that pgindent would fail if you try to use a too-old copy of pg_bsd_indent...) regards, tom lane [1] Um, well, actually the existing behavior is to scan to the *first* right paren. But upgrading it to count parens correctly seems like an unobjectionable improvement in any case.