On 2016-02-12 09:47:47 -0500, Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > On Fri, Feb 12, 2016 at 9:39 AM, Tom Lane <tgl@sss.pgh.pa.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.
Well, for some reason c.h has been written to allow for that for a long
time. I think it's fairly unlikely that somebody writes a _Bool
implementation where sizeof(_Bool) is bigger than sizeof(char). Although
that'd be, by my reading of the standard. permissible. It just says
6.2.5-2: An object declared as type _Bool is large enough to store the values 0 and 1.
6.7.2.1: While the number of bits in a _Bool object is at least CHAR_BIT, the width (number of sign and value
bits)of a _Bool may be just 1 bit.
afaics that's pretty much all said about the size of _Bool, except some
bitfield special cases.
But we also only support e.g. CHAR_BIT = 8, so I'm not super concerned
about _Bool being defined too wide.
Andres