Downsides of scanning all .o files for typedefs

I'd been getting weird results for the last couple of days while
pgindent-ing various patches.  I eventually realized that the cause
was that the current typedefs list marks "c", "string", and a few
other common words as typedefs.  This seems pretty uncool.  Further
investigation shows that the reason is that these names are used as
typedefs in a couple of the ecpg regression tests; which the old
find_typedefs code never picked up on, but the OS X implementation
does.

Now, it's actually rather pointless to collect typedef names from
the ecpg tests, since pgindent won't process files with .pgc
extensions anyway (and I doubt it would work well to try).

So we could either revise these test cases to use less-generic
typedef names, or we could just skip ecpg/test/ in find_typedefs.
For the moment I've got dromedary using the attached quick-hack patch
to do the latter.  Any thoughts on the best long-term answer?

            regards, tom lane

diff -c build-farm-4.12.orig/run_build.pl build-farm-4.12/run_build.pl
*** build-farm-4.12.orig/run_build.pl    Sat Apr  5 17:15:45 2014
--- build-farm-4.12/run_build.pl    Sat Apr  5 23:13:37 2014
***************
*** 1533,1540 ****
      {

          # On OS X, we need to examine the .o files
          my $obj_wanted = sub {
!             /^.*\.o\z/s && push(@testfiles, $File::Find::name);
          };

          File::Find::find($obj_wanted,$pgsql);
--- 1533,1541 ----
      {

          # On OS X, we need to examine the .o files
+         # exclude ecpg/test, which pgindent does too
          my $obj_wanted = sub {
!             /^.*\.o\z/s && ! ($File::Find::name =~ m!/ecpg/test/!s) && push(@testfiles, $File::Find::name);
          };

          File::Find::find($obj_wanted,$pgsql);