Hi,

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 <phi...@tecnocode.co.uk> wrote:
> Hi,
>
> On Mon, 2014-12-22 at 14:42 -0500, sduclos wrote:
>> Hi,
>>
>> 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.

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:

http://stackoverflow.com/questions/50605/signed-to-unsigned-conversion-in-c-is-it-always-safe

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!


thanks,

Sylvain.

>
> Philip
>
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Reply via email to