Re: more GDK->GTK mapping

[Havoc Pennington <hp redhat com>]

Oskar Liljeblad <osk hem passagen se> writes: 
> I agree. Shouldn't be too hard to change that typedef, since all code
> that relies on gboolean being signed is broken anyway...
> Besides, why isn't boolean defined like this:
> 
> 	typedef uint{8,16,32,64}_fast_t gboolean;
> 
> About uintXX_fast_t from the GNU libc manuals:
> 
>      If you don't need a specific storage size, but want the data
>   structure that allows the fastest access while having at least N bits
>   (and among data structures with the same access speed, the smallest
>   one), use one of these: [..]
> 
> I don't know how well that would work with bitfields though...
> 

gboolean used to be a gchar or guchar (some 8-bit thing), and we had
all kinds of problems with varargs and signal marshallers and such,
since C will implicitly convert types to plain "int" in some cases.
At some point we got fed up with bugs related to that and just changed
gboolean to int, since in all cases where size mattered we were using
bitfields anyhow.

Owen is on a bit of a "unsigned sucks" campaign and most new APIs that
he was involved in don't use unsigned int at all, because we've also
had a bunch of bugs resulting from underflow or mixing signed with
unsigned. 

"unsigned int" maybe avoids passing in negative values, but we catch
those mistakes with g_return_if_fail() anyhow, and those mistakes are
much less common and much easier to find than weird
underflow/signedness-mixing bugs. It's quite common that a loop which
appears to terminate actually becomes infinite due to the use of uint,
for example.

That said making gboolean unsigned isn't totally ridiculous, it's
certainly better than introducing a gboolean_bitfield type just for
bitfields, and presumably you don't normally use arithmetic or the <>
operators on booleans so don't see all the weirdness uints normally
introduce. But it would require some careful evaluation and thinking,
and might have some unexpected side effects, and so my impulse would
be that it's not really worth it. The problem being solved is not
large enough to merit much effort/breakage/confusion.

Havoc