Re: Lessons from commit fest - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: Lessons from commit fest
Date
Msg-id 8763ufc0ch.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: Lessons from commit fest  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Lessons from commit fest  (Andrew Dunstan <andrew@dunslane.net>)
Re: Lessons from commit fest  (Greg Smith <gsmith@gregsmith.com>)
List pgsql-hackers
"Tom Lane" <tgl@sss.pgh.pa.us> writes:

"Tom Lane" <tgl@sss.pgh.pa.us> writes:

> Gregory Stark <stark@enterprisedb.com> writes:
>> "Tom Lane" <tgl@sss.pgh.pa.us> writes:
>
>> 1) I take it we feel safe guaranteeing that we won't use any fancy macros
>>    inside typedefs. So no '#define pgtype(x) _pg_##x' or anythin like that.
>
> Hmm ... we are fairly crawling with struct tags built that way:
>
> /* Introduces a catalog's structure definition */
> #define CATALOG(name,oid)    typedef struct CppConcat(FormData_,name)
>
> but offhand I can't think of any actual typedef names built with ##.
> Does indent need a preset list of struct tags?  Seems that would be
> stupid ...

It's not just ## that's a problem. Any macro used to build the typedef would
be a problem. There's not a whole lot of other reasons you would want to use
macros in a typedef but...

>> 3) How would this work with typedefs which come from system or library
>>    includes?
>
> Ouch, that's a real good point.  Maybe a certain amount of platform
> dependence is inevitable.

The reason I was asking these questions was because I was thinking about how
hard it would be to generate the list from a textual analysis instead of using
object files.

Such a tool *cannot* use cpp to preprocess the file because it would defeat
much of the purpose. The point is that we want to find all the typedefs in all
the #ifdef branches.

But if we don't preprocess the files with CPP then macros like the one I
included before wouldn't be interpreted. Nor would we be pulling in system or
library headers, so no typedefs from them.

But if we're just interested in the names I suppose a hybrid approach would
work. 1) The build farm builds a list of typedefs found in all the various
builds and we check that into CVS. 2) a textual tool run as part of your
normal build builds a list of typedefs found in your tree.

But if we're still doing object file analysis on the build farm and it's easy
to add typedefs manually then perhaps there's not much effort saved by having
such a tool. I think it would be possible to write but it wouldn't really be
easy. You have to parse just enough C to find the typedef but not so much you
get confused by invalid C syntax caused by looking at both sides of #ifdef
branches.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support!


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Plan targetlists in EXPLAIN output
Next
From: Andrew Dunstan
Date:
Subject: Re: Lessons from commit fest