Re: GinPageIs* don't actually return a boolean

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: GinPageIs* don't actually return a boolean
Дата
Msg-id 20160212134841.ernnio7cnugjgbd4@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: GinPageIs* don't actually return a boolean  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: GinPageIs* don't actually return a boolean  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Dmitry Ivanov
Дата:
Сообщение: Re: GinPageIs* don't actually return a boolean
Следующее
От: Fujii Masao
Дата:
Сообщение: Re: Incorrect formula for SysV IPC parameters