Re: [HACKERS] incorrect const usage
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] incorrect const usage |
Дата | |
Msg-id | 4655.922723575@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | incorrect const usage (Dmitry Samersoff <dms@wplus.net>) |
Список | 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 по дате отправления: