Re: [HACKERS] taking stdbool.h into use

Michael Paquier <michael@paquier.xyz>

From: Michael Paquier <michael@paquier.xyz>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Andres Freund <andres@anarazel.de>, Michael Paquier <michael.paquier@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Alvaro Herrera <alvherre@alvh.no-ip.org>, pgsql-hackers <pgsql-hackers@postgresql.org>, Thomas Munro <thomas.munro@enterprisedb.com>
Date: 2018-03-20T06:13:05Z
Lists: pgsql-hackers
On Tue, Mar 13, 2018 at 03:25:39PM -0400, Peter Eisentraut wrote:
> After more digging, there are more problems with having a bool that is
> not 1 byte.  For example, pg_control has a bool field, so with a
> different bool size, pg_control would be laid out differently.  That
> would require changing all the mentions of bool to bool8 where the end
> up on disk somehow, as I had already done for the system catalog
> structures, but we don't know all the other places that would be affected.
> 
> So I'm going back to my proposal from December, to just use stdbool.h
> when sizeof(bool) == 1, and add a static assertion to prevent other
> configurations.

So, on one side of the ring, we have more complicated patches to include
so as support for sizeof(bool) == 4 becomes possible in the backend
code, and on the opposite side one patch which restrains the use of
stdbool.h only when the size is 1.  A size of 4 bytes for bool is
defined in stdbool.h on a small set of platforms, so it could be
tempting to use what is proposed here, still that feels like a
halk-baked integration.  Thoughts from others?
--
Michael

Commits

  1. Use stdbool.h if suitable

  2. Add configure tests for stdbool.h and sizeof bool

  3. Remove useless use of bit-masking macros

  4. Change various Gin*Is* macros to return 0/1.

  5. Fix several possibly non-portable gaffs in record_image_ops.