On 13-08-18 03:34 AM, Dimitar Zhekov wrote:
On Sun, 18 Aug 2013 02:32:34 -0700 Matthew Brush mbrush@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