On 2016-02-12 09:47:47 -0500, Tom Lane wrote: > Robert Haas <robertmh...@gmail.com> writes: > > On Fri, Feb 12, 2016 at 9:39 AM, Tom Lane <t...@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-54f81ef6e...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers