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
|
Список | 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 по дате отправления: