[cairo] Adding a boolean type

[Ned Konz]

On Monday 31 January 2005 4:02 pm, Owen Taylor wrote:
> Working with Cairo, I've gotten annoyed by using int/0/1 for booleans.
> It makes the code harder to read to have to decipher what is an int
> and what is a boolean.
>
> What if we add:
>
>  typedef char cairo_bool_t;
>  #define CAIRO_FALSE 0
>  #define CAIRO_TRUE  1
>
> Issues:
>
>  char vs. int: For Glib we picked int, to reduce the risk of
>    'GBoolean bool = flags & FLAG' traps, but mostly it doesn't matter,
>    and char seems to be more common in general.
>
>  CAIRO_FALSE vs. FALSE: For GLib, FALSE/TRUE are pretty much the
>    only exception's to the namespace. We do:
>
>      #ifndef FALSE
>      #define FALSE 0
>      #endif
>
>    and I don't think we've ever had reports of problems. And the
>    reduced typing is nice...
>
> What do people think?

(1) Standard C has had the _Bool (and bool if you include <stdbool.h>) for 
some time now (5 years or so). Ideally we should stay compatible with the 
standard, and allow using the standard _Bool type if it exists.

(2) Using char for a bool_t keeps you from declaring groups of bool_t in 
bitfields, at least if you want to be compatible with Standard C:

struct {
   char b1: 1;
 char b2: 1;
 char b3: 1; } // not legal Standard C

vs.

struct {
 unsigned int b1: 1; // OK

etc.

(3) you may get diagnostics from your compiler or lint, since the default C 
promotion to int will result in initializing from, assigning, and comparing 
dissimilar types:

cairo_bool_t myBool = CAIRO_FALSE; // initializing char from int

if (myBool == (3 == 4)) { ... }  // comparing char to int

I'd suggest using an unsigned int or int as the bool_t type, for these 
reasons.

-- 
Ned Konz
http://bike-nomad.com/squeak/