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


On Tue, 2014-12-23 at 06:40 -0500, sduclos wrote:

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?

Not really relevant.

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.

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!


Attachment: signature.asc
Description: This is a digitally signed message part

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