Heikki Linnakangas <hlinnaka@iki.fi> writes:
> On 05/19/2017 06:48 PM, Tom Lane wrote:
>> That's going to catch a lot of things that are just variables, though.
>> It might be all right as long as there was manual filtering after it.
> At a quick glance, there are only a couple of them. This two cases
> caught my eye. In twophase.c:
> static struct xllist
> {
> ...
> } records;
> IMHO it would actually be an improvement if there was a space rather
> than a tab there.
Agreed, but if "records" were considered a typedef name, that would
likely screw up the formatting of code referencing it. Maybe less
badly with this version of indent than our old one, not sure.
What I was just looking at is the possibility of absorbing struct
tags ("xllist" in the above) as if they were typedef names. In
at least 95% of our usages, if a struct has a tag then the tag is
also the struct's typedef name. The reason this is interesting
is that it looks like (on at least Linux and macOS) the debug info
captures struct tags even when it misses the corresponding typedef.
We could certainly create a coding rule that struct tags *must*
match struct typedef names for our own code, but I'm not sure what
violations of that convention might appear in system headers.
regards, tom lane
