Why would anyone use gboolean (GLib) instead of bool type?

Question

I've been reading some code which uses gtk+ and I've encountered types like gboolean and gunichar.

As long as I can understand the point of using gunichar instead of wchar_t (glib gunichar and wchar_t), I can't really understand the point of using gboolean instead of bool.

Question: What's the point of using gboolean instead of bool? Is there something more than just being careful about the code style consistency?

It wouldn't be so weird to me if it were used for a general consistency (if one decides to use GLib, one'll prefer to use types defined there). However the author of that code uses int instead of gint. Is the author just being careless?

---

Just to add more details (official GLib as a reference):

• gunichar is defined as typedef guint32 gunichar

• guint32 is defined as typedef unsigned int guint32

• gboolean is defined as typedef gint gboolean

• gint is defined as typedef int gint

Answer 1

Uniformity and maintainability. If at a certain point in future a new utf8char type is introduced, it will only be a matter of changing the typedef and recompiling, without having to go through thousands of lines of code to patch every single usage.

Also consider that GLib is meant to work on a wide range of compilers, not all fully compliant with the latest specs. For instance, the availability of bool, wchar_t and fixed-size types cannot be assumed, since they all came with C99 and C11. Furthermore, GLib development began in 1998 (as you can see from the contributors graph), when C99 was still in draft and those features weren't even standard.

Answer 2

Recently discovered it's not just merely about consistency; there is actually caveat involved when dealing with big endian platforms.

On big endian platforms tested so far (PowerPC32, Sparc64, etc) g_option_context_parse() would fail to deal with argument declared with C99 _Bool, as if the relevent options were completely ignored. Switch to gboolean and everything works again. This problem is not present in little endian platforms.

I'm not sure if it's intentional behavior, but the internal parsing of G_OPTION_ARG_NONE type arguments are all handled using gboolean, which is equivalent to native integer in terms of occupied byte size, while _Bool occupies 1 byte only. Probably that explains the problem under big endian environment.