Re: bool: symbol name collision - Mailing list pgsql-bugs

From bryanh@giraffe-data.com (Bryan Henderson)
Subject Re: bool: symbol name collision
Date
Msg-id 8371.bryanh@giraffe-data.com
Whole thread Raw
In response to Re: bool: symbol name collision  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: bool: symbol name collision
List pgsql-bugs
>Um, our code has
>
>#ifndef __cplusplus
>
>#ifndef bool
>typedef char bool;
>#endif
>
>#ifndef true
>#define true    ((bool) 1)
>#endif
>
>etc.
>
>so somehow it was once thought that it is worth supporting other
>definitions of bool.

And the Postgres manual says you can use C++ (34.9 - C-Language Functions:
"User defined functions can be written in C (or a language that can be made
compatible with C, such as C++)."  If in fact the code as it stands is what
the developers want, then C++ cannot be made compatible with C for Postgres
purposes because there's no way to make "bool" not a reserved word in C++.  So
the manual should be changed to explicitly say you better not use C++ because
the fmgr.h interface will probably not work.  And the same goes for any code
that happens to define a "bool" macro and doesn't define it to "char".

It's pretty clear looking at this code that the author never expected "bool"
to be part of an interface structure.

If renaming "bool" is not acceptable, you should at least change this code to
do a #error if it isn't the same size as "char".

If you look at a bunch of other systems that have C interfaces, I don't think
you'll find any that define "bool" in a header file that a user is supposed to
#include in his program.  You will find some that use boolean variables, but
they define some "my_bool" type for it.  I've noticed this since way before
C99 standardized "bool".

>It would break far too much existing code,

There must be a dozen ways to avoid this problem that have no effect on
existing code and are superior to what I do now.  What I do now is patch
fmgr.h to change all instances of "bool" to "char" and, after installing,
chop the "bool" section out of c.h.

Here's one that's one step better than local modifications to Postgres: define
both "bool" and "pgbool" to the same thing in c.h and use only pgbool in
fmgr.h.  In c.h, put the "bool" definition under #ifdef
POSTGRES_DONT_DEFINE_BOOL .

>it would be
>better if Bryan could show us a concrete example that is causing
>problems.

I don't know how concrete you want.  A user defined function server extension
#includes a header file that #includes another that #includes the C99 standard
header file <stdbool.h>.  The server extension also #includes <postgres.h>.
The compile fails with the multiple definition of type "bool".

Here's a worse one (but hypothetical; I haven't actually done this): the
server extension is compiled with a C++ compiler that uses 4 bytes for "bool".
Everything compiles, but the PG_GETARG_INT32() call gets the wrong argument
because the server thinks bool is one byte while the server extension thinks
it is 4.

--
Bryan Henderson                                   San Jose, California

pgsql-bugs by date:

Previous
From: bryanh@giraffe-data.com (Bryan Henderson)
Date:
Subject: Re: reference to undefined macro _MSC_VER
Next
From: Greg Stark
Date:
Subject: Re: bool: symbol name collision