Re: [glib] Why is g_ptr_array_set_size take a gint instead of guint for the length parameter?
Le 23/12/2014 14:02, jcup...@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. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [glib] Why is g_ptr_array_set_size take a gint instead of guint for the length parameter?
Hi >> 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. Correct, not relevant at all .. but this all I could find .. hence my e-mail to this list to ask for the proper place to look. You told me that this gint/guint is probably an oversight and that is all we need to know. Case close as far as I'm concern. >> 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! OK no problem .. maybe push this in glib 3.0 ! I'm just a random internet guy. So let me know if I need to do something else. As I said, this thread document the gint/guint of g_ptr_array and I think ours job is done! Thanks again Philip, Sylvain. > > Philip > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [glib] Why is g_ptr_array_set_size take a gint instead of guint for the length parameter?
>> >> 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. The uints scattered through xlib are a good example of the confusion they can cause. The argument the other way would be that declaring it unsigned gives extra information about what "length" means (it's a number of things, not a distance). I guess that point of view won out. I agree that the inconsistency is annoying and puzzling. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [glib] Why is g_ptr_array_set_size take a gint instead of guint for the length parameter?
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 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 signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [glib] Why is g_ptr_array_set_size take a gint instead of guint for the length parameter?
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 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
Re: [glib] Why is g_ptr_array_set_size take a gint instead of guint for the length parameter?
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); g_ptr_array_set_size() was introduced in 1998 (commit df9a49ec), and has not been modified since. The commit message introducing it doesn't mention anything about choosing gint as the type, other than that GPtrArray itself is similar to java.lang.Vector. 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 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. Philip signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
