Thread

1. Patch to include c.h

   Gurjeet Singh <singh.gurjeet@gmail.com> — 2012-09-16T13:49:35Z

   I noticed that xlog.h uses PGDLLIMPORT, but it does not include c.h
   directly or indirectly. Also, in timestamp.h different code is enabled
   depending on HAVE_INT64_TMESTAMP being defined, but even though that macro
   is defined in pg_config.h, it does not automatically trickle down into this
   file, as it is supposed to.
   
   Apparently all .c files manage to include c.h (directly or indirectly)
   before including these files, so the compilers do the right thing. But I
   caught these since I tried using an IDE, and it grays out sections to, or
   shows error-markers when it doesn't find a macro included directly or
   indirectly.
   
   I vaguely remember a discussion where (I think) Bruce mentioned that we do
   or intend to do some kind of compilability check on individual h files. DO
   we have something in place to catch such things? I am sure there are many
   other places where such inclusions are omitted, but these are the ones I
   found on my first attempts to use this IDE.
   
   Best regards,
   -- 
   Gurjeet Singh
   
   http://gurjeet.singh.im/
   

2. Re: Patch to include c.h

   Tom Lane <tgl@sss.pgh.pa.us> — 2012-09-16T15:52:54Z

   Gurjeet Singh <singh.gurjeet@gmail.com> writes:
   > I noticed that xlog.h uses PGDLLIMPORT, but it does not include c.h
   > directly or indirectly.
   
   In general, all include files in Postgres assume that you've included
   postgres.h or postgres_fe.h (as appropriate) first; and practically
   all of them have far more dependencies on that than you mention here.
   If we were to decorate them with explicit inclusions such as you propose,
   we would accomplish little except to bloat the sources and slow down
   compilation.
   
   The general rule about that is "thou shalt have no other gods before
   c.h" --- that is, it is *necessary* that c.h be included before anything
   else, in *every* Postgres file.  Otherwise you can run into
   platform-specific problems.  An example I remember is individual files
   having different ideas of whether 64-bit or 32-bit filesystem APIs are
   in use, as a consequence of <stdio.h> being read before pg_config_os.h
   has defined symbols controlling that.  Needless to say, this doesn't
   work well at runtime.  You can find actual examples of that sort of
   thing in the archives from years ago, before we began to enforce the
   rule rigidly.
   
   			regards, tom lane
   
   
   

3. Re: Patch to include c.h

   Gurjeet Singh <singh.gurjeet@gmail.com> — 2012-09-17T13:49:17Z

   On Sun, Sep 16, 2012 at 11:52 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
   
   > Gurjeet Singh <singh.gurjeet@gmail.com> writes:
   > > I noticed that xlog.h uses PGDLLIMPORT, but it does not include c.h
   > > directly or indirectly.
   >
   > In general, all include files in Postgres assume that you've included
   > postgres.h or postgres_fe.h (as appropriate) first;
   
   
   Thankfully, this IDE provides for me to specify preprocessor directives
   that are processed before parsing any source files, so it was easy for me
   to #include "c.h" in every file.
   
   So, that solved the problem for me, but other IDEs may not be so flexible.
   
   I understand that I am supposed to include postgres.h in backend files, and
   postgres_fe.h in frontend files, like those of psql, pg_dump, ecpg, etc.,
   but I didn't bother with that for now. If I proceed with this IDE, then I
   think it'll make sense to have a project per client program, so that I can
   include postgres_fe.h for those projects, and postgres.h for the main
   backend project.
   
   and practically
   > all of them have far more dependencies on that than you mention here.
   > If we were to decorate them with explicit inclusions such as you propose,
   > we would accomplish little except to bloat the sources and slow down
   > compilation.
   >
   
   True, it would affect the compilation times, but I think if one is using
   ccache, then they would be sheilded from this on second and subsequent runs.
   
   
   >
   > The general rule about that is "thou shalt have no other gods before
   > c.h" --- that is, it is *necessary* that c.h be included before anything
   > else, in *every* Postgres file.  Otherwise you can run into
   > platform-specific problems.  An example I remember is individual files
   > having different ideas of whether 64-bit or 32-bit filesystem APIs are
   > in use, as a consequence of <stdio.h> being read before pg_config_os.h
   > has defined symbols controlling that.  Needless to say, this doesn't
   > work well at runtime.  You can find actual examples of that sort of
   > thing in the archives from years ago, before we began to enforce the
   > rule rigidly.
   >
   
   I'm glad that we have this rule in place.
   
   Best regards,
   -- 
   Gurjeet Singh
   
   http://gurjeet.singh.im/