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