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 659923 - Add g_variant_new_fixed_array() function
Add g_variant_new_fixed_array() function
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: gvariant
unspecified
Other Linux
: Normal enhancement
: ---
Assigned To: Allison Karlitskaya (desrt)
gtkdev
Depends on:
Blocks:
 
 
Reported: 2011-09-23 08:53 UTC by Stef Walter
Modified: 2011-09-25 06:27 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
gvariant: Add g_variant_get_fixed_array() (5.65 KB, patch)
2011-09-23 08:58 UTC, Stef Walter
needs-work Details | Review
Thanks for the review. Does this look good to go in? (6.41 KB, patch)
2011-09-24 08:23 UTC, Stef Walter
none Details | Review
Errr, now with fixed indentation. How's that? (6.42 KB, patch)
2011-09-24 08:25 UTC, Stef Walter
accepted-commit_now Details | Review

Description Stef Walter 2011-09-23 08:53:22 UTC
Using g_variant_new_from_data() for creating new byte arrays is non-obvious. This patch adds a g_variant_new_fixed_array() function.
Comment 1 Stef Walter 2011-09-23 08:58:53 UTC
Created attachment 197326 [details] [review]
gvariant: Add g_variant_get_fixed_array()

Using g_variant_new_from_data() for creating new byte arrays is non-obvious.
This patch adds a g_variant_new_fixed_array() function.
Comment 2 Allison Karlitskaya (desrt) 2011-09-23 15:43:51 UTC
Review of attachment 197326 [details] [review]:

Thanks a lot Stef.  This looks almost exactly right.  Just some minor details in the implementation...

::: glib/gvariant.c
@@ +1148,3 @@
+	gpointer data;
+
+	g_return_val_if_fail (g_variant_type_is_definite (element_type), NULL);

in addition to checking that the type is definite, you should also check that it is fixed-sized (ie: bools, bytes, int/uint{16,32,64}, doubles and maybe fd array indices).

you should also check that the user's given element_size is correct as per the type.

g_variant_type_info_query_element could help here, but i'm not completely sure how i feel about using it from gvariant.c (since it's normally only used in gvariant-core.c).

@@ +1152,3 @@
+
+	data = g_memdup (elements, n_elements * element_size);
+	return g_variant_new_from_data (g_variant_type_new_array (element_type),

this leaks the array GVariantType
Comment 3 Stef Walter 2011-09-24 08:23:27 UTC
Created attachment 197386 [details] [review]
Thanks for the review. Does this look good to go in?

Updated attachment to check that element size matches element_type, and check
that element_type represents a type with a fixed size.

Used g_variant_type_info_query_element() for this, as its already used
elsewhere in gvariant.c in g_variant_get_fixed_array(). 

Fixed leaks, tested (by hand) that criticals fire when invalid stuff is passed.
Comment 4 Stef Walter 2011-09-24 08:25:31 UTC
Created attachment 197387 [details] [review]
Errr, now with fixed indentation. How's that?
Comment 5 Allison Karlitskaya (desrt) 2011-09-24 16:59:09 UTC
Review of attachment 197387 [details] [review]:

Feel free to push this with the very minor tweak.

Thanks very much (and thanks for writing a test, too).

::: glib/gvariant.c
@@ +1165,3 @@
+                    array_element_size, element_size);
+      else
+        g_critical ("g_variant_get_fixed_array: array does not have fixed size.");

you should return NULL after the g_criticals()
Comment 6 Stef Walter 2011-09-25 06:27:57 UTC
Great. Merged with that change.