Re: g{u}int{8|16|32} patch (again)

[Tim Janik <timj gtk org>]

On 22 Aug 2001, Mathieu Lacage wrote:

> hi all,
> 
> I must have been in a weird state the other day: I fucked up my patch.
> Here is a working patch which does not include g{u}int64 support (I can
> produce this on demand. just ask for it.)
> 
> In case anyone wants to know why I want this to get in, it is because,
> without this patch, it would be impossible to have signals or object
> properties to use these types. Many people will ask me why in hell I

not true, UINT8/INT8 are already implemented, they're just called UCHAR/CHAR.
INT32/UINT32 is also handled by INT/UINT already, and that won't change
because glib/gdk/gtk contains lots of code that relies on sizeof(gint)>=32.

as in C integer function arguments <=sizeof(int) are always promoted to
int, there's no huge benefit in using CHAR/INT8/INT16 over INT for
signal parameter types. though CHAR probably is a bit different here, in
that it's often used conceptually as "character" not as "8bit wide int",
which one might want to carry across in the signal argument types.
i fail to see that being the case for "16bit wide int", so you could
just use INT there and only emit signals with -32768 <= arguments <= 32767.

for object properties there's really no point in INT8/INT16 because
g_param_spec_int() lets you define the exact range of validity for
your properties. so g_param_spec_int8(...,-128,127) is by no means
better than g_param_spec_int(...,-128,127).

> cannot use gint and guint for the 8, 16 and 32 quantities. The first
> reason is simply that I am not sure gint will always fit a 32 bit
> quantity (is there a way to be sure about this ?) and the second reason
> is that doing so would weaken my API: it would make it less precise.
> 
> I hope that this patch will be considered for inclusion quickly: please,
> owen or tim, could you comment on it  and tell me why you won't want it
> ?

btw, types other than gint can't be lcopy-ied by value_lcopy_int, and there's
no point in adding extra fields to GValue, v_int/v_uint serve 8/16/32 bit
wide integers perfectly well.

> 
> regards,
> Mathieu
> 

---
ciaoTJ