Hi, On Tue, 2014-12-23 at 06:40 -0500, sduclos wrote:
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.
You mean this? https://bugzilla.gnome.org/show_bug.cgi?id=422939 Not really relevant.
On 12/23/14, Philip Withnall <philip 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.
That's where the problem lies. We can't change gint to guint without breaking API. The change would introduce new compiler warnings (converting signed to unsigned integer) in modules which previously didn't have any, which GLib guarantees to avoid. I'm not entirely sure whether it would be an ABI break (don't have time to trawl through the C specification at the moment). I guess it wouldn't be, since the only valid uses of that API are where (0 ≤ len ≤ G_MAXINT), which is binary compatible regardless of whether the function is expecting a signed or unsigned integer.
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.
I agree that it would make the API more pleasing, but I don't think we can justify the API break. Sorry! Philip
Attachment:
signature.asc
Description: This is a digitally signed message part