Re: GinPageIs* don't actually return a boolean

From: Andres Freund <andres(at)anarazel(dot)de>
To: pgsql-hackers(at)postgresql(dot)org
Cc: Teodor Sigaev <teodor(at)sigaev(dot)ru>
Subject: Re: GinPageIs* don't actually return a boolean
Date: 2015-08-11 15:46:51
Message-ID: 20150811154651.GE17575@awork2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2015-08-11 17:42:37 +0200, Andres Freund wrote:
> Hi,
>
> #define GinPageIsLeaf(page) ( GinPageGetOpaque(page)->flags & GIN_LEAF )
> #define GinPageIsData(page) ( GinPageGetOpaque(page)->flags & GIN_DATA )
> #define GinPageIsList(page) ( GinPageGetOpaque(page)->flags & GIN_LIST )
> ...
>
> These macros don't actually return a boolean that's comparable with our
> true/false. That doesn't strike me as a good idea.
>
> If there's actually a boolean type defined by some included header (in
> which case we don't overwrite it in c.h!) this actually can lead to
> tests failing. If e.g. stdbool.h is included in c.h the tests fail with
> gcc-4.9.

I guess the reason here is that if it's a boolean type known to the
compiler it's free to assume that it only contains true/false...

> I think we should add a !! to these macros to make sure it's an actual
> boolean.
>
> This has been the case since gin's initial commit in 8a3631f8d86cdd9b0 .

Even worse, we have that kind of macro all over. I thought
e.g. HeapTupleHeaderIs* would be safe agains that, but that turns out
not be the case.

Greetings,

Andres Freund

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Verite 2015-08-11 15:49:01 Re: [patch] A \pivot command for psql
Previous Message Fabien COELHO 2015-08-11 15:44:01 pgbench bug in head