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


Thanks for the info .. I didn't thought checking the repo.
There is one entree in Bugzilla about  g_ptr_array_set_size () from 2007.

On 12/23/14, Philip Withnall <philip tecnocode co uk> wrote:

On Mon, 2014-12-22 at 14:42 -0500, sduclos wrote:

I'm looking for the rational of using 'gint' instead of 'guint' in the

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

Well, looking at the code, length is used against len a couple of time in all
code path. This force the compiler to typecast gint into guint, say:

On the other hand, if guint is used instead of gint, only the caller
that use gint would need to typecast.

But what happen to legacy code that use pass a gint/guint to a
g_ptr_array_set_size(..., guint lenght) is a bit foggy for me.

I assume that this has been debated to death .. but I can't find where!

I can't find anything either. It probably hasn't; it's fairly
unimportant. If you've got an array with more than 2^31 elements, you
should probably be using something other than an array.

Well we get rid of useless friction and also it normalize the interface.
Agree that 2^31 is plenty but for my use case, g_ptr_array it is the fastest.
Rather then returning to the user a pointer to an internal object in my lib
I return an index to a g_ptr_array of internal pointer .. it's safer - no
risk of dangling pointer for instance.

Note that g_array_ would do the same for me.

I just wanted to highlight the fact that in garray.c; g_array,
g_ptr_array, g_byte_array use guint and surprisingly only
g_ptr_array_set_size use gint.

And this thread document that!




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]