Re: GinPageIs* don't actually return a boolean

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: GinPageIs* don't actually return a boolean
Дата
Msg-id 14287.1455288467@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: GinPageIs* don't actually return a boolean  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: GinPageIs* don't actually return a boolean  (Yury Zhuravlev <u.zhuravlev@postgrespro.ru>)
Re: GinPageIs* don't actually return a boolean  (Andres Freund <andres@anarazel.de>)
Re: GinPageIs* don't actually return a boolean  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Feb 12, 2016 at 9:39 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Um, no, that does not follow.  The unanswered question here is why,
>> when we *have not* included stdbool.h and *have* typedef'd bool as
>> just plain "char", we would get C99 bool behavior.

> http://www.postgresql.org/message-id/d2106c2d-0f46-4cf9-af27-54f81ef6e20c@postgrespro.ru
> seems to explain what happens pretty clearly.  We #include something
> which #includes something which #includes something which #includes
> <stdbool.h>.  It's not that surprising, is it?

Well, the thing that is scaring me here is allowing a platform-specific
definition of "bool" to be adopted.  If, for example, the compiler
writer decided that that should be int width rather than char width,
all hell would break loose.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: GinPageIs* don't actually return a boolean
Следующее
От: Andres Freund
Дата:
Сообщение: Re: CustomScan in a larger structure (RE: CustomScan support on readfuncs.c)