After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 657100 - Implement g_variant_peek_strv() + friends
Implement g_variant_peek_strv() + friends
Status: RESOLVED WONTFIX
Product: glib
Classification: Platform
Component: gvariant
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Allison Karlitskaya (desrt)
gtkdev
Depends on:
Blocks:
 
 
Reported: 2011-08-22 18:57 UTC by David Zeuthen (not reading bugmail)
Modified: 2011-08-22 21:33 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description David Zeuthen (not reading bugmail) 2011-08-22 18:57:49 UTC
The code generated by gdbus-codegen(1) is designed in a way so the generated code has non-reffing getters so it's easy to use in the case where your GDBusProxy or GDBusInterfaceSkeleton is used from the same thread as you've got it from.

Right now gdbus-codegen(1) implements this in a very clumsy way that includes allocating memory etc. My plan, however, is to change this by directly accessing the memory in the GVariant instance (in the GDBusProxy case).

This is however complicated by the fact that

 const gchar **g_variant_get_strv()

expects you to free the container (and I know why it's implemented this way). So I would like to propose

 const gchar * const *g_variant_peek_strv()
 (including _objv and _bytestring_array variants)

that frees the container for you when finalizing the GVariant instance. That way I won't have to do that in generated code.

Thanks for considering.
Comment 1 David Zeuthen (not reading bugmail) 2011-08-22 19:15:26 UTC
Hmm, I thought GVariant had qdata. Turns out it doesn't so implementing this means growing the GVariant struct by 8 bytes :-/. Hmm, I don't _strictly_ need this feature (after all, I can track the strv container myself) so if you think that cost is too big, feel free to close...
Comment 2 Allison Karlitskaya (desrt) 2011-08-22 21:33:50 UTC
I've often considered tucking extra information into GVariant instances, and this is an example.  Another is caching children so that they don't need to be deserialised again.  I've always decided that it's not worth the trouble.

I'll close this for now...