bry...@giraffe-data.com (Bryan Henderson) writes:
> How about something less drastic? Could you at least eliminate "bool" from
> interface structures that are intended to be compiled in multiple
> environments?
No. That's not distinguishably different from eliminating it altogether.
On Wed, May 12, 2010 at 1:01 PM, Peter Eisentraut wrote:
> The problem with the bool type is that it could have different sizes on
> different systems. Which will lead to problems. I doubt that that
> problem exists with int4.
>
I could imagine macros that do the wrong thing if the types they u
On ons, 2010-05-12 at 12:44 +0100, Greg Stark wrote:
> Well you could imagine doing this for all our types by doing:
>
> search and replace int4 -> pgint4 etc.
> add #ifndef int4 #define int4 pgint4 at the end of postgres.h
>
> That way third-party apps which define their own int4 would be
> requ
On Tue, May 11, 2010 at 8:47 PM, Tom Lane wrote:
> Alex Hunsaker writes:
>
>> You mean i'd get the pleasure of 'fixing' all my 3rd party C modules?
>
> Yeah, it's the implications for 3rd-party modules that make me not want
> to do this. A search & replace on our own code base is one thing, but
>Yeah, that may well be. I don't think we should have a policy of
>folding our arms and shouting "no" whenever someone asks us to clean
>up our namespace, but on the flip side one request (or even two) is
>probably not enough reason to do anything drastic, and this would be
>fairly drastic.
How a
>On the flip side if the code that purports to cope with other
>definitions of bool is useless, we should remove it so as to avoid
>giving the impression that we have any ability to so cope.
Indeed, that code is what led me to believe I could work around my bool
conflict problem with a "#define bo
On Tue, May 11, 2010 at 3:47 PM, Tom Lane wrote:
> Alex Hunsaker writes:
>> On Tue, May 11, 2010 at 12:42, Robert Haas wrote:
>>> I guess the question that comes to mind for me is how many other
>>> things fall into this category. We define a lot of symbols like int4
>>> and int32 that other pe
On tis, 2010-05-11 at 14:42 -0400, Robert Haas wrote:
> I guess the question that comes to mind for me is how many other
> things fall into this category. We define a lot of symbols like int4
> and int32 that other people could also have defined, and I don't
> really want to s/^/pg/ all of them.
Alex Hunsaker writes:
> On Tue, May 11, 2010 at 12:42, Robert Haas wrote:
>> I guess the question that comes to mind for me is how many other
>> things fall into this category. Â We define a lot of symbols like int4
>> and int32 that other people could also have defined, and I don't
>> really wan
On Tue, May 11, 2010 at 12:42, Robert Haas wrote:
> I guess the question that comes to mind for me is how many other
> things fall into this category. We define a lot of symbols like int4
> and int32 that other people could also have defined, and I don't
> really want to s/^/pg/ all of them. If
On Tue, May 11, 2010 at 1:08 PM, Peter Eisentraut wrote:
> On mån, 2010-05-10 at 15:55 +, Bryan Henderson wrote:
>> >>> 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 eluci
On mån, 2010-05-10 at 15:55 +, Bryan Henderson wrote:
> >>> 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 i
>>> It's quite annoying and
>>> sad that they added "bool" to c99 since otherwise it would just be a
>>> drop-in replacement with extra functionality and very low risk of
>>> conflicts. Instead they virtually guaranteed conflicts with any large
>>> software over a single define.
>
>For that reason
>>> 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 heade
On mån, 2010-05-10 at 02:02 +0100, Greg Stark wrote:
> I don't see any other conflicts offhand that would create problems
> using a c99 compiler to build server modules. It's quite annoying and
> sad that they added "bool" to c99 since otherwise it would just be a
> drop-in replacement with extra f
On sön, 2010-05-09 at 17:37 +, 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 heade
On Sun, May 9, 2010 at 6:04 PM, Tom Lane wrote:
> Huh? We build just fine on C99 compilers, AFAIK. Or are you saying
> that we should try to adopt 's definition of bool? The
> problem there is, again, that we don't know what width that will be.
No, I'm saying we should use something like pgboo
>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
Greg Stark writes:
> On Sun, May 9, 2010 at 5:58 PM, Tom Lane wrote:
>> Yeah, I know those #if's are there, but whether they actually do
>> anything useful is highly questionable. There is no reason to assume
>> that a compiler's built-in version of bool will be bit-compatible with
>> ours. And
On Sun, May 9, 2010 at 5:58 PM, Tom Lane wrote:
> Yeah, I know those #if's are there, but whether they actually do
> anything useful is highly questionable. There is no reason to assume
> that a compiler's built-in version of bool will be bit-compatible with
> ours. And changing the width of boo
Peter Eisentraut writes:
> On sön, 2010-05-09 at 11:35 -0400, Tom Lane wrote:
>> ... we consider building server extensions with C++ to be
>> unsupported anyway.
> Um, our code has
> #ifndef __cplusplus
> #ifndef bool
> typedef char bool;
> #endif
> etc.
Yeah, I know those #if's are there, b
On sön, 2010-05-09 at 11:35 -0400, Tom Lane wrote:
> bry...@giraffe-data.com (Bryan Henderson) writes:
> > The interface header files for Postgres server extensions define "bool",
> > but that name is commonly used by other parts of user code, including
> > by standards (C99, C++). That causes, at
bry...@giraffe-data.com (Bryan Henderson) writes:
> The interface header files for Postgres server extensions define "bool",
> but that name is commonly used by other parts of user code, including
> by standards (C99, C++). That causes, at best, compile failures.
> If Postgres has to define a boo
The interface header files for Postgres server extensions define "bool",
but that name is commonly used by other parts of user code, including
by standards (C99, C++). That causes, at best, compile failures.
If Postgres has to define a boolean type in public header files, it should
use a name tha
24 matches
Mail list logo
