Re: [HACKERS] incorrect const usage - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] incorrect const usage
Date
Msg-id 4655.922723575@sss.pgh.pa.us
Whole thread Raw
In response to incorrect const usage  (Dmitry Samersoff <dms@wplus.net>)
List pgsql-hackers
Dmitry Samersoff <dms@wplus.net> writes:
> Problem caused by incorrect const tag usage still exist
> cc: Error: fe-connect.c, line 173: In this declaration, parameter 1 has a
> different type than specified in an earlier declaration of this function.
> PQconnectdb(const char *conninfo)

Ugh.  Apparently you're getting bit by c.h's gratuitous#define const
when _STDC_ is not set.  This really ought to be handled by a direct
test whether CONST is usable; in fact that whole "#ifdef __STDC__"
section of c.h is pretty bogus.  I will work on it.

The problem wouldn't have come up, except that libpq-fe.h doesn't
include config.h or c.h anymore (to avoid polluting application
namespace with huge amounts of Postgres-internal symbols).  So the uses
of "const" in libpq-fe.h are seen by the compiler before it sees the
#define, and then when it hits the actual function definitions inside
libpq, it (rightly) complains.

What that means is that no one has yet tried to compile 6.4.* on a
compiler that doesn't recognize "const" (or if anyone did, they didn't
report its failure).  Considering that we require compilers to support
ANSI-style function definitions, and "const" predates ANSI, it seems
unlikely that there'd be any hope of building Postgres with such a
compiler anyway.  In short: we could probably just lose the "#define const"
entirely, as well as a lot of the other alleged support for pre-ANSI
compilers in c.h.

>   or (worst) patch configure to add -std to CFLAGS

What's worst about that?  If your compiler is not really ANSI without it,
it seems like a good idea to me.  What is your platform exactly?
Does it have a template file?  Adding -std to CFLAGS in the template
would be simple enough...
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] libpq++
Next
From: Vince Vielhaber
Date:
Subject: Re: [HACKERS] libpq++