GNOME Bugzilla – Bug 666918
Some functions returning const strings have ownership issues
Last modified: 2021-06-10 11:28:09 UTC
for example on AtkDocument get_document_locale() and get_document_attribute_vaue() these functions are fine if there is a preexisting const string somewhere you can return a pointer to. However if this isn't the case and you must retrieve the attributes value then you must allocate storage for the object somewhere. However since it is expected the returned string should not be freed the implementation must arrange for the string to be deallocated at some point in the future. However there is no time after which it must be true that the caller has no references to the returned string.
(In reply to comment #0) > for example on AtkDocument get_document_locale() and > get_document_attribute_vaue() these functions are fine if there is a > preexisting const string somewhere you can return a pointer to. However if > this isn't the case and you must retrieve the attributes value then you must > allocate storage for the object somewhere. However since it is expected the > returned string should not be freed the implementation must arrange for the > string to be deallocated at some point in the future. Well, this is general for any abstract library that include some methods returning "const gchar*". Although it is true that in some cases this is more likely to happen, this can also happen to methods as common as atk_object_get_name, in the case that you need to reimplement this method. Usually that means that the accessibility object need to cache those strings for some time. > However there is no > time after which it must be true that the caller has no references to the > returned string. And again, this is general for any call to a "const gchar*" method. The caller can't assume that the reference will be available forever. For example if you call gtk_label_get_text, you shouldn't use that pointer "too much time". If this is the case, you should make a copy. Anyway, it is true that in some cases is debatable if have sense to have them as "const gchar*". And as this is a API breakage I will add the dependency to bug 638537 (metabug that summarizes API breakages towards ATK 3.X)
(In reply to comment #1) > (In reply to comment #0) > > for example on AtkDocument get_document_locale() and > > get_document_attribute_vaue() these functions are fine if there is a > > preexisting const string somewhere you can return a pointer to. However if > > this isn't the case and you must retrieve the attributes value then you must > > allocate storage for the object somewhere. However since it is expected the > > returned string should not be freed the implementation must arrange for the > > string to be deallocated at some point in the future. > > Well, this is general for any abstract library that include some methods > returning "const gchar*". Although it is true that in some cases this is more > likely to happen, this can also happen to methods as common as > atk_object_get_name, in the case that you need to reimplement this method. true > Usually that means that the accessibility object need to cache those strings > for some time. of course, that is the "best" solution given this interface. > > However there is no > > time after which it must be true that the caller has no references to the > > returned string. > > And again, this is general for any call to a "const gchar*" method. The caller > can't assume that the reference will be available forever. For example if you > call gtk_label_get_text, you shouldn't use that pointer "too much time". If > this is the case, you should make a copy. of course, while I don't have a wonderful replacement in mind I think this is a pretty poor interface, made worse by the fact how long the caller can expect to use the pointer is unspecified. > Anyway, it is true that in some cases is debatable if have sense to have them > as "const gchar*". And as this is a API breakage I will add the dependency to > bug 638537 (metabug that summarizes API breakages towards ATK 3.X) agree, thanks for fixing the deps.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version of atk, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a ticket at https://gitlab.gnome.org/GNOME/atk/-/issues/ Thank you for your understanding and your help.