Re: GinPageIs* don't actually return a boolean

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Yury Zhuravlev <u(dot)zhuravlev(at)postgrespro(dot)ru>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, Teodor Sigaev <teodor(at)sigaev(dot)ru>
Subject: Re: GinPageIs* don't actually return a boolean
Date: 2016-02-12 14:47:47
Message-ID: 14287.1455288467@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Fri, Feb 12, 2016 at 9:39 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2016-02-12 14:56:45 Re: CustomScan in a larger structure (RE: CustomScan support on readfuncs.c)
Previous Message Andres Freund 2016-02-12 14:47:35 Re: GinPageIs* don't actually return a boolean