Re: [libvirt] proposal: allow use of "bool": HACKING: discuss C types
"Daniel P. Berrange" <berrange(a)redhat.com> wrote:
On Fri, Dec 12, 2008 at 09:58:32AM +0100, Jim Meyering wrote:
> I propose to allow (encourage, even) the use of the standard C99 type,
> bool, in libvirt, but not in public interfaces[1]. There are already
> uses in cgroup.c and xmlrpc.c, as well as those in the gnulib "c-ctype.h"
> header which is included from many of libvirt's .c files.
>
> The motivation is to make the code as readable as possible.
> When you see the declaration of an "int" variable, member, or function,
> that type gives you no clue whether it is used as a boolean. If you
> see a few uses that treat it as boolean, that's still no guarantee,
> and it may be non-trivial to ensure that there isn't some non-boolean
> value with a special meaning.
>
> However, if you see a "bool" variable, you do have that guarantee.
I don't particularly like the idea of using the bool type
- No system header files use it
Of course. Can't use it there for the same reason that we wouldn't
use it in libvirt's own public interfaces, as I explained. But public
interfaces make up such a small fraction of the code in question that
it'd be a shame to impose its restrictions on all the rest.
- Library header files which use a boolean type have nearly all
defined
their own custom bool types, not using stdbool.h and there's no guarentee
that stdbool's idea of 'true' matches the other apps'
This is the same fundamental restriction.
"bool" cannot be used in public headers.
- We don't use it in the public API, or on the wire for the
remote
protocol, since it has undefined size.
Same point.
- The GNULIB bool emulation is unable to provide equivlance between
C's idea of true (any non-zero value) and the defined 'true'
constant (whose value is 1)
That sounds scary, but isn't an issue in practice.
The uses of "true" and "false" are typically only for
initialization. IMHO, one should never compare a bool-declared
variable to "true" or "false".
- Bitfields are more size efficient than bools.
It's not about size, but rather readability.
In a language like python where there's a fundamental builtin
type in
the language for 'bool' this it makes sense. In the C world with many
many[1] different definitions of bool, true and false it just feels
The number of definitions is because people find it useful
to expose the semantics of the type, yet realize that
they cannot use that precise name in a header file.
like a world of hurt. The only thing you can ultimately rely on is
that
a true value is non-zero.
There is no hurt in my experience.
It's used extensively in gnulib-using projects, and