Re: [glib] Why is g_ptr_array_set_size take a gint instead of guint for the length parameter?

[Colomban Wendling <lists ban herbesfolles org>]

Le 23/12/2014 14:02, jcupitt gmail com a écrit :
> > > > > I'm looking for the rational of using 'gint' instead of 'guint' in the
> > > > > call:
> > > > >
> > > > > g_ptr_array_set_size (GPtrArray *array, gint length);
> > >
> > > > I imagine that the use of a signed integer was an oversight at the time
> > > > which can now not be corrected without breaking API. It's not worth
> > > > that.
>
> I remember (a long, long time ago) there was a dislike for uint.
> Mixing uint and int can be fiddly and produce a range of bugs, some
> more subtle than others, and the extra bit of range you get is
> unimportant. int-only code is usually simpler and safer.

It's far from being that simple.  There is for example a whole history
of out of bound buffer access triggered by signed integer wraparound [1]
and missing checks for < 0.  With unsigned you can't suffer from this
(directly).  But OK, unsigned integer "overflow" can also lead to
infinite loops or under-allocations in some special cases.

But well, this is C, it's a tricky language.  But IMO, yes, unsigned has
a lot of benefits when it comes to sizes, and is overall safer than the
signed version.  And in the large majority of cases, a correctly
designed code that always uses unsigned sizes won't suffer from mixed
signedness.

size_t (or gsize) TFW :)

Colomban


[1] as while signed integer overflow is technically undefined behavior
(which is bad enough), it generally ends up in a wraparound to MIN_INT
due to the machine integer representation.