incorrect const usage

Started by Dmitry Samersoffalmost 27 years ago2 messages
#1Dmitry Samersoff
dms@wplus.net

Problem caused by incorrect const tag usage still exist

It can be solved
whether to check all calls for const modifyier
or remove all const tags
or (worst) patch configure to add -std to CFLAGS

kernigan(dms)~/pgsql/pgsql/src/interfaces/libpq>uname -a
OSF1 kernigan.wplus.net V4.0 878 alpha

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)
^

---
Dmitry Samersoff, dms@wplus.net, ICQ:3161705
http://devnull.wplus.net

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Dmitry Samersoff (#1)
Re: [HACKERS] incorrect const usage

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