Re: bool: symbol name collision

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Bryan Henderson <bryanh(at)giraffe-data(dot)com>
Cc: tgl(at)sss(dot)pgh(dot)pa(dot)us, pgsql-bugs(at)postgresql(dot)org
Subject: Re: bool: symbol name collision
Date: 2010-05-10 12:39:13
Message-ID: 1273495153.11359.24.camel@fsopti579.F-Secure.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On sön, 2010-05-09 at 17:37 +0000, Bryan Henderson wrote:
> >it would be
> >better if Bryan could show us a concrete example that is causing
> >problems.
>
> I don't know how concrete you want.

Something one can download and compile.

> 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".

Well, let's say including stdbool.h is not supported then. ;-)

> 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.

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. There is a test script for this in
src/tools/pginclude/cpluspluscheck.

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Peter Eisentraut 2010-05-10 13:09:08 Re: bool: symbol name collision
Previous Message Takahiro Itagaki 2010-05-10 06:34:19 Re: "SET search_path" clause ignored during function creation