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

> 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