GNOME Bugzilla – Bug 401176
Use const for g_slist_length() and g_list_length()
Last modified: 2017-09-11 21:41:14 UTC
guint g_list_length (GList *list); g_slist_length() does not modify list, so it could use (const GList *list). This would make it possible to use the function in user-made functions that got a parameter of type const GList * (without getting a warning). Same applies to g_list_length().
Created attachment 157625 [details] [review] Bug 401176 — Use const for g_slist_length() and g_list_length() Make various GList and GSList functions take const lists. Closes: bgo#401176
I think that patch is wrong - at least in places. It doesn't preserve constness in the way a developer would expect it. g_list_prev (g_list_next(const_list)) is non-const with your patch, and that shouldn't work. To make those functions work properly, you'd need to make the return value depend on the constness of the input (i.e. the returned GList is const if the passed in GList is const, but this is not possible to express. And I don't think it's a good idea to repeat the brokenness of strchr() and related functions that just cast away the constness. At least it has been the policy in glib to not use const at all if it cannot be expressed well - which is why no GObject subclass is ever used const.
Aargh, I didn't put myself on the CC list. Sorry. (In reply to comment #2) > I think that patch is wrong - at least in places. It doesn't preserve constness > in the way a developer would expect it. g_list_prev (g_list_next(const_list)) > is non-const with your patch, and that shouldn't work. To make those functions > work properly, you'd need to make the return value depend on the constness of > the input (i.e. the returned GList is const if the passed in GList is const, > but this is not possible to express. And I don't think it's a good idea to > repeat the brokenness of strchr() and related functions that just cast away the > constness. The only way I've come across to represent this would be to have two functions: one which takes a const input, and one which takes a non-const input (both giving the appropriate outputs), but that's just ugly. Probably best to leave functions like g_list_[next|prev]() then, as you say. That still leaves: * g_list_copy() * g_list_position() * g_list_index() * g_list_length() * g_list_nth_data() and their GSList counterparts which can be constified, yes? > At least it has been the policy in glib to not use const at all if it cannot be > expressed well - which is why no GObject subclass is ever used const. That makes sense. Is it documented anywhere?
(In reply to comment #3) > Probably best to leave functions like g_list_[next|prev]() then, as you say. > That still leaves: > * g_list_copy() > * g_list_position() > * g_list_index() > * g_list_length() > * g_list_nth_data() > and their GSList counterparts which can be constified, yes? > I would not object to that if other maintainers decided it's a good idea, but I lean slightly against it for the do-not-use-const-at-all reason below. > > At least it has been the policy in glib to not use const at all if it cannot be > > expressed well - which is why no GObject subclass is ever used const. > > That makes sense. Is it documented anywhere? > Unfortunately I've never found a place where things like these are documented as they usually get into common usage without anyone ever writing them down. I wouldn't even know where to look for them.
This is a very old subject, see, e.g.: http://mail.gnome.org/archives/gtk-devel-list/2001-May/msg00485.html
(In reply to comment #4) > (In reply to comment #3) > > Probably best to leave functions like g_list_[next|prev]() then, as you say. > > That still leaves: > > * g_list_copy() > > * g_list_position() > > * g_list_index() > > * g_list_length() > > * g_list_nth_data() > > and their GSList counterparts which can be constified, yes? > > > I would not object to that if other maintainers decided it's a good idea, but I > lean slightly against it for the do-not-use-const-at-all reason below. I guess the toss-up is between using const to help as much as it can, even though it can never be a perfect solution (for all the reasons above and in the mailing list thread), and the inconsistency that would cause in the API by having some things const and others not for seemingly no apparent reason.
Just fyi, bug #614684, bug #397125, bug #303543, bug #583036 and bug #547199 are along the same lines, and might want to be taken into consideration.
(In reply to Benjamin Otte (Company) from comment #2) > At least it has been the policy in glib to not use const at all if it cannot > be expressed well - which is why no GObject subclass is ever used const. For this reason, let’s leave these APIs unmodified then.
Review of attachment 157625 [details] [review]: --