Re: boolean in C

Hi folks,

Today I got bitten a bit, trying to write C function for postgresql,
that also includes some of company's internal stuff. Needles to say,
our stuff defines BOOL, as well as postgresql's c.h include file.

Now, for us, we will probably change it, but is there any reason for
postgresql nowadays not to use stdbool.h, apart from fact, that no one
made an effort ? Having said that, wouldn't it be easy as just
replacing all TRUE/FALSE/BOOL with lowercase ones, and including
stdbool from c.h ?

--On 16. Juli 2009 11:12:34 +0100 Grzegorz Jaskiewicz <gj(at)pointblue(dot)com(dot)pl>
wrote:

> Now, for us, we will probably change it, but is there any reason for
> postgresql nowadays not to use stdbool.h, apart from fact, that no one
> made an effort ? Having said that, wouldn't it be easy as just replacing
> all TRUE/FALSE/BOOL with lowercase ones, and including stdbool from c.h ?

If i remember correctly, older SUN compilers doesn't have it. Don't know if
that is still an issue yet, but we need to take care for non-gcc compilers
i think.

--
Thanks

Bernd

On 16 Jul 2009, at 12:52, Bernd Helmle wrote:

>
>
> --On 16. Juli 2009 11:12:34 +0100 Grzegorz Jaskiewicz <gj(at)pointblue(dot)com(dot)pl
> > wrote:
>
>> Now, for us, we will probably change it, but is there any reason for
>> postgresql nowadays not to use stdbool.h, apart from fact, that no
>> one
>> made an effort ? Having said that, wouldn't it be easy as just
>> replacing
>> all TRUE/FALSE/BOOL with lowercase ones, and including stdbool from
>> c.h ?
>
> If i remember correctly, older SUN compilers doesn't have it. Don't
> know if that is still an issue yet, but we need to take care for non-
> gcc compilers i think.
For those guys, we could just put in c.h as it is now...

oh, another thing.
stdbool is C99 standard feature. Not gcc extension.
Just in case, someone thinks otherwise.

Grzegorz Jaskiewicz <gj(at)pointblue(dot)com(dot)pl> writes:
> oh, another thing.
> stdbool is C99 standard feature.

We are still targeting C89, not C99.

Another reason not to depend on stdbool is that, so far as I can see,
the standard does not promise that type _Bool has size = 1 byte.
We have to have that because of on-disk compatibility requirements.

regards, tom lane

On 16 Jul 2009, at 14:20, Tom Lane wrote:

> Grzegorz Jaskiewicz <gj(at)pointblue(dot)com(dot)pl> writes:
>> oh, another thing.
>> stdbool is C99 standard feature.
>
> We are still targeting C89, not C99.
>
> Another reason not to depend on stdbool is that, so far as I can see,
> the standard does not promise that type _Bool has size = 1 byte.
> We have to have that because of on-disk compatibility requirements.

I think the latter is easily fixable, or forceable to be one byte.
Why C89, and not C99 ? Virtually all compilers for last 4 years have/
had C99 support.

Grzegorz Jaskiewicz <gj(at)pointblue(dot)com(dot)pl> writes:
> Why C89, and not C99 ? Virtually all compilers for last 4 years have/
> had C99 support.

Not everybody is running a compiler released within the last 4 years.

The short answer is that C99 doesn't appear to offer enough advantage
over C89, *for our purposes*, to justify freezing out older systems.
stdbool is a perfect example of an addition that offers precisely
zero actual functional improvement. All it would be for us is an
additional autoconf headache and portability hazard.

regards, tom lane

On Thursday 16 July 2009 16:23:31 Grzegorz Jaskiewicz wrote:
> On 16 Jul 2009, at 14:20, Tom Lane wrote:
> > Grzegorz Jaskiewicz <gj(at)pointblue(dot)com(dot)pl> writes:
> >> oh, another thing.
> >> stdbool is C99 standard feature.
> >
> > We are still targeting C89, not C99.
> >
> > Another reason not to depend on stdbool is that, so far as I can see,
> > the standard does not promise that type _Bool has size = 1 byte.
> > We have to have that because of on-disk compatibility requirements.
>
> I think the latter is easily fixable, or forceable to be one byte.

How do you plan to do that?

> Why C89, and not C99 ? Virtually all compilers for last 4 years have/
> had C99 support.

Well, I think we want to run on systems that are older than 4 years, too.

On 16 Jul 2009, at 14:53, Peter Eisentraut wrote:

> On Thursday 16 July 2009 16:23:31 Grzegorz Jaskiewicz wrote:
>> On 16 Jul 2009, at 14:20, Tom Lane wrote:
>>> Grzegorz Jaskiewicz <gj(at)pointblue(dot)com(dot)pl> writes:
>>>> oh, another thing.
>>>> stdbool is C99 standard feature.
>>>
>>> We are still targeting C89, not C99.
>>>
>>> Another reason not to depend on stdbool is that, so far as I can
>>> see,
>>> the standard does not promise that type _Bool has size = 1 byte.
>>> We have to have that because of on-disk compatibility requirements.
>>
>> I think the latter is easily fixable, or forceable to be one byte.
>
> How do you plan to do that?
by casting it to 1 byte type such as char ?
I don't think anyone will add 3rd state to boolean in stdbool, at
least not any time soon :)

And it is pretty annoying, when your product also has its own BOOLean
defined...

>
>> Why C89, and not C99 ? Virtually all compilers for last 4 years have/
>> had C99 support.
>
> Well, I think we want to run on systems that are older than 4 years,
> too.

Sure, but that's probably less than 1% of all systems.
The 4 years was a guess, I think its much more than that.

Grzegorz Jaskiewicz <gj(at)pointblue(dot)com(dot)pl> writes:
> On 16 Jul 2009, at 14:53, Peter Eisentraut wrote:
>>>> the standard does not promise that type _Bool has size = 1 byte.
>>>> We have to have that because of on-disk compatibility requirements.

>>> I think the latter is easily fixable, or forceable to be one byte.

>> How do you plan to do that?

> by casting it to 1 byte type such as char ?

That's hardly going to improve readability for anyone. Also, it will
flat out not work for the catalog struct declarations. When we say
"bool relhasindex;" the compiler had better think that that's a
one-byte field.

> And it is pretty annoying, when your product also has its own BOOLean
> defined...

IOW you're not using stdbool either?

regards, tom lane

On 16 Jul 2009, at 15:17, Tom Lane wrote:

> Grzegorz Jaskiewicz <gj(at)pointblue(dot)com(dot)pl> writes:
>
> That's hardly going to improve readability for anyone. Also, it will
> flat out not work for the catalog struct declarations. When we say
> "bool relhasindex;" the compiler had better think that that's a
> one-byte field.

Sure, but I would certainly hope, there's not too many places where
you actually convert it from disc representation, to internal and vice
versa.

>
>> And it is pretty annoying, when your product also has its own BOOLean
>> defined...
>
> IOW you're not using stdbool either?

Well, saying that I don't is quite an overstatement. It was decided
long before I started working for that customer, and is full of
problems like that. But still,
it would be nice for postgresql to at least not cause problems like
that. Having said that, I will probably fix it on customer's side, but
I wanted to see if you guys will be happy with patch that changes that
in postgresql.

thanks .

Grzegorz Jaskiewicz píše v čt 16. 07. 2009 v 14:59 +0100:

> >
> >> Why C89, and not C99 ? Virtually all compilers for last 4 years have/
> >> had C99 support.
> >
> > Well, I think we want to run on systems that are older than 4 years,
> > too.
>
>
> Sure, but that's probably less than 1% of all systems.
> The 4 years was a guess, I think its much more than that.

For example Solaris 8 is 9 years old and still is used in production. I
guess HP-UX is in same situation. And so on. I not able to say how many
PostgreSQL runs on them but how Tom mentioned there is no significant
reason to break old platform.

Zdenek

Grzegorz Jaskiewicz <gj(at)pointblue(dot)com(dot)pl> writes:
> On 16 Jul 2009, at 15:17, Tom Lane wrote:
>> That's hardly going to improve readability for anyone. Also, it will
>> flat out not work for the catalog struct declarations. When we say
>> "bool relhasindex;" the compiler had better think that that's a
>> one-byte field.

> Sure, but I would certainly hope, there's not too many places where
> you actually convert it from disc representation, to internal and vice
> versa.

We don't "convert" --- it's expected to be the same representation.
As for not too many of them, I think grepping for references to bool
catalog fields will show you differently ...

regards, tom lane