Re: bool: symbol name collision

>>> I don't know how concrete you want.
>
>Something one can download and compile.

That wouldn't be worth anyone's effort, since the problem is esaily enough
elucidated with a few words of explanation. I.e. I'm sure you can imagine
writing a program that would demonstrate the problem of two header files
that both typedef "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.
>
>You should use PG_GETARG_BOOL(). I don't see why this necessarily
>couldn't work.

Sorry, I should have been more explicit about how it screws up the interface
to have "bool" mean something different when you compile a server extension
from what it means when you compile Postgres. Postgres and the user function
pass back and forth a struct FunctionCallInfoData. It contains such things as
the array of argument values. It has one member, before the argument array,
that fmgr.h defines as type "bool". Now if the user program thinks "bool" is
4 bytes and Postgres thinks it is 1 byte, the user program and Postgres will
disagree about the offsets of every field after that. The way the alignment
works out, the effect is that the memory the user program looks to for
Argument 3 is the memory in which Postgres placed Argument 4. So
PG_GETARG_INT32(3) does not get Argument 3.

But this is just a practical example of the general principle that an
interface cannot use types that are specific to the environment on one end of
the interface. Which is how I know whoever wrote the c.h code that says,
"if the environment already has bool, just use it" didn't expect "bool" to
be used in an interface between Postgres and something else.

>We did actually include a sizable patch into 9.0 to remove conflicts
>with C++ reserved words (typename and such). I don't recall any
>complaints about bool at the time.

Bear in mind that this isn't a syntax error - the compiler simply generates
the wrong code.

--
Bryan Henderson San Jose, California