Re: GinPageIs* don't actually return a boolean - Mailing list pgsql-hackers

From Andres Freund
Subject Re: GinPageIs* don't actually return a boolean
Date
Msg-id 20160212134841.ernnio7cnugjgbd4@alap3.anarazel.de
Whole thread Raw
In response to Re: GinPageIs* don't actually return a boolean  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: GinPageIs* don't actually return a boolean
List pgsql-hackers
On 2016-02-12 07:59:06 -0500, Robert Haas wrote:
> OK, that seems reasonable from here.  What I'm still fuzzy about is
> why including stdbool.h causes a failure. Is it because it defines a
> type called "bool" that clashes with ours?  That seems like the
> obvious explanation, but then how does that not cause the compiler to
> just straight-up error out?

No, that's not the problem. Our own definition is actually
conditional. The problem is that the standard's booleans behave
differently. They only ever contain 0 or 1, even if you assign something
outside of that range - essentially they store !!(right-hand-side).  If
you know compare a boolean with the values returned by one of these
macros you'll get into problems.

E.g. if you include stdbool.h:
Buffer
ginStepRight(Buffer buffer, Relation index, int lockmode)
{bool        isLeaf = GinPageIsLeaf(page);bool        isData = GinPageIsData(page);
...if (isLeaf != GinPageIsLeaf(page) || isData != GinPageIsData(page))    elog(ERROR, "right sibling of GIN page is of
differenttype");
 

doesn't work correctly because isLeaf/isData contain only 0/1 (due to
the standard's bool behaviour), but the values they're compared to
returns some bit set. Due to integer promotion rules isLeaf is promoted
to an integer and compared... And thus the tests fail.

Andres



pgsql-hackers by date:

Previous
From: Dmitry Ivanov
Date:
Subject: Re: GinPageIs* don't actually return a boolean
Next
From: Fujii Masao
Date:
Subject: Re: Incorrect formula for SysV IPC parameters