Date: Sun, 4 Jan 2004 05:40:15 -0800 (PST) From: Bruce Evans <bde@zeta.org.au> To: freebsd-standards@FreeBSD.org Subject: Re: standards/60772: _Bool and bool should be unsigned Message-ID: <200401041340.i04DeFaw031541@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR standards/60772; it has been noted by GNATS.
From: Bruce Evans <bde@zeta.org.au>
To: Jonathan Lennox <lennox@cs.columbia.edu>
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: standards/60772: _Bool and bool should be unsigned
Date: Mon, 5 Jan 2004 00:39:01 +1100 (EST)
On Fri, 2 Jan 2004, Jonathan Lennox wrote:
> Notice also PR bin/48958 -- in RELENG_4, the 'bool' type isn't
> binary-compatible between C and C++. Another reason to drop it from
> RELENG_4.
Hmm. The absence of stdbool.h in glibc-2.2.5 is mostly likely just
because <stdbool.h> is part of gcc (glibc doesn't have stddef.h either).
We have gcc's stdbool.h in RELENG_4 but don't install it. It uses:
% typedef enum
% {
% false = 0,
% true = 1
% } bool;
This causes slightly different problems than typedef "int bool". I
noticed the following:
- non-problem: the enum is apparently implemented as an unsigned int,
so assignments of "true" to a bitfield of width 1 work right.
- bitfields can't have type enum for C compilers (according to TenDRA),
so the above is very unportable.
- bool can hold values other than true and false. So can bool bitfields
of width larger than 1.
- same binary compability problem as "int bool". Enums apparently always
have the same size and alignment as int in gcc, presumably because enums
are too much like ints to be very useful.
I think we can't just unsupport it, since gcc has it.
Approx. 20 ports reference stdbool.h in their patches.
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200401041340.i04DeFaw031541>