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

From Robert Haas
Subject Re: GinPageIs* don't actually return a boolean
Date
Msg-id CA+TgmoZP5KakLGP6B4vUjgMBUW0woq_dJYi0paOz-My0Hwt_vQ@mail.gmail.com
Whole thread Raw
In response to GinPageIs* don't actually return a boolean  (Andres Freund <andres@anarazel.de>)
Responses Re: GinPageIs* don't actually return a boolean  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Tue, Aug 11, 2015 at 11:42 AM, Andres Freund <andres@anarazel.de> wrote:
> #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.

!! is unknown to our codebase except where you've added it, and
personally, I hate that idiom.  I think we should write (val) != 0
instead of !!val.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: "Daniel Verite"
Date:
Subject: Re: [patch] A \pivot command for psql
Next
From: Andres Freund
Date:
Subject: Re: GinPageIs* don't actually return a boolean