[Geany-Devel] Geany using standard types

Matthew Brush mbrush at xxxxx
Sun Aug 18 10:56:01 UTC 2013


On 13-08-18 03:34 AM, Dimitar Zhekov wrote:
> On Sun, 18 Aug 2013 02:32:34 -0700
> Matthew Brush <mbrush at codebrainz.ca> wrote:
>
>> "Do you agree it would be better for Geany to use standard C types as
>> opposed to GLib types which are typedef'd to the exact same thing?" (ex.
>> gint->int, glong->long, gchar->char etc.)
>
> Yes.
>
>> - I left gboolean where it would break a function signature with respect
>> to GCC warnings.
>
> Understandable.
>
>> - I left all guchar, gushort, guint, gulong, etc types, because, lets be
>> honest, it's just nicer to type.
>
> In my Geany [2013-06-16], there are 43 guchar, gushort and gulong; 475
> guint, 1420 gint and 2091 gchar. It is easier to type guint instead
> of unsigned - the keys are near - but it is worth to mix the standard
> and GLib types?
>
> Personally I'm using gchar if a string may be UTF-8, and char where
> it's guaranteed to be ASCII or it's unknown and doesn't matter - to
> remind me that such string is logically not a direct array of char.
>

That sounds like quite a useful differentiation.

>> - I think patch includes changes to stdint types (ex. gint16, guint32)
>> but I think we shouldn't change these as GLib assures them and the C99
>> standard does not in theory (and is not many in use).
>
> AFAIK GLib does not emulate unexistent integer types.
> If they exist && we are using C99, they will be defined as u/intN_t.
>

I thought this too, but it seems that glibconfig.h (or similarly named 
header, generated from glib configure.ac using lots of shell magic), is 
not ever using C99/stdint.h types even if they exists - at least 
according to ebassi (core dev). They just always figure out the right 
sized type using shell and preprocessor magic.

My concern here with stdint.h was that if CHAR_BIT > 8 then C99 forbids 
an implementation from defining int8_t and if int8_t isn't defined then 
uint8_t can't be defined.  And if this is true [citation needed], and 
you couldn't rely on (u)int8_t, then might as well just stick to 
portable GLib typedefs.

Cheers,
Matthew Brush


More information about the Devel mailing list