Re: GinPageIs* don't actually return a boolean - Mailing list pgsql-hackers

From Andres Freund
Subject Re: GinPageIs* don't actually return a boolean
Date
Msg-id 20150811154651.GE17575@awork2.anarazel.de
Whole thread Raw
In response to GinPageIs* don't actually return a boolean  (Andres Freund <andres@anarazel.de>)
List 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



pgsql-hackers by date:

Previous
From: Fabien COELHO
Date:
Subject: pgbench bug in head
Next
From: "Daniel Verite"
Date:
Subject: Re: [patch] A \pivot command for psql