[Libreoffice] Purpose of easy task 'Get rid of sal_uLong' ?

[Tor Lillqvist]

> Also its really not something only LO does:
> 
> http://www.gtk.org/api/2.6/glib/glib-Basic-Types.html 

Whoa, stop there.

I can assure you that C code written in the "GLib/GTK+ style" definitely does *not* use gint32 or guint32 all over the place, if that was what you were hinting at.

gint32 and guint32 are used only in very specific cases where the code explicitly wants to use 32 bits on all platforms in all cases, like marshalling to/from some serialized data structure.

Otherwise it's int or its equivalent gint that is used. And yes, many of these people do care a lot about warning-free code, for example compiling GIMP is not supposed to produce warnings, as far as I know. 

gint64 and guint64 are used in places where it is known that 32 bits is not enough, even if it isn't specifically exactly 64 bits that is necessarily wanted. Yes, that is wrong: Perhaps, some day, when we have machines where 128-bit integral types are equally natural and fast as 64-bit ones are today, this will be seen as a bad decision, and what should have been used instead would be some "gint64orlonger" type.

(I guess I should point out that GLib and the GTK+ stack are portable only to platforms where int is at least 32 bits.)

And yes, many do feel that the typedefs gint, guint, gchar and guchar in GLib are a bit silly, as it is 100% equivalent to just use int, unsigned int, char or unsigned char instead. Others do like to use them just for visual consistency in the code. Myself, I don't care that much, I use whatever the surrounding code does, and if writing completely new GTK+ code (which I hardly ever do) I use just int and char and not gint or gchar.

(With "GLib/GTK+ style I mean the style used by people that have been involved in writing and designing the GTK+ stack themselves, a typical example would be GIMP.)

--tml