This confused me for a while, because it isn't the same as D-Bus.
Like GVariant, the D-Bus serialization needs an out-of-band
endianness and type indicator, but unlike GVariant, serialized
D-Bus objects encapsulate their own length (often by starting with
a byte-count). This does come at some redundancy cost, so I can see
why the more efficient GVariant format does this the way it does;
but it's a difference between D-Bus and GVariant that seems worth
calling out.
It's also relevant for the designers of file or message-framing
formats: with D-Bus serialization it would be feasible to say "the file
starts with a little-endian D-Bus variant, followed by...",
but in GVariant you wouldn't be able to deserialize the variant
unless you either assume that it extends to end-of-file, or have
an explicit length.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=736975
Reviewed-by: Ryan Lortie
Since we are no longer using sgml mode, using /* */ to
escape block comments inside examples does not work anymore.
Switch to using line comments with //
Since all element markup is now gone from the doc comments,
we can turn off the gtk-doc sgml mode, which means that from
now on, docbook markup is no longer allowed in doc comments.
To make this possible, we have to replace all remaining
entities in doc comments by their replacement text, & -> &
and so on.
Slightly expand on the documentation about casting varargs when
constructing GVariants, and link to it from all the functions where it’s
a necessary consideration.
Add an example of passing flags to a ‘t’ type variable (guint64).
Assuming the flags enum does not have many members, the flag variable
will be 32 bits wide, and needs an explicit cast to be passed into
g_variant_new() as a 64-bit value.
https://bugzilla.gnome.org/show_bug.cgi?id=712837
Fix some leaks that turned up while valgrinding the GVariant testcase.
These leaks are small and only occur when there is already an error in
the program: they are leaks of temp strings used when formatting a
critical message.
These show up as leaks again the testcase under the new "expect
messages" approach. Previously, we fork()ed and these caused the
subprocess to abort, which is why this was not noticed before.
Back in the far-off twentieth century, it was normal on unix
workstations for U+0060 GRAVE ACCENT to be drawn as "‛" and for U+0027
APOSTROPHE to be drawn as "’". This led to the convention of using
them as poor-man's ‛smart quotes’ in ASCII-only text.
However, "'" is now universally drawn as a vertical line, and "`" at a
45-degree angle, making them an `odd couple' when used together.
Unfortunately, there are lots of very old strings in glib, and also
lots of new strings in which people have kept up the old tradition,
perhaps entirely unaware that it used to not look stupid.
Fix this by just using 'dumb quotes' everywhere.
https://bugzilla.gnome.org/show_bug.cgi?id=700746
Lots of people have variously asked for APIs like
g_variant_new_string_printf() in order to avoid having to use
g_strdup_printf(), create a GVariant using g_variant_new_string(), then
free the temporary string.
Instead of supporting that, plus a million other potential cases,
introduce g_variant_new_take_string() as a compromise.
It's not possible to write:
v = g_variant_new_take_string (g_strdup_printf (....));
to get the desired result and avoid the extra copies. In addition, it
works with many other functions.
https://bugzilla.gnome.org/show_bug.cgi?id=698455
For some time now people have been asking for a way to check for type
compatibility between GVariant instances and format strings. There are
several APIs inside of GLib itself that would benefit from this.
This patch introduces a way to do that.
* Represents an immutable reference counted block of memory.
* This is basically the internal glib GBuffer structure exposed,
renamed, and with some additional capabilities.
* The GBytes name comes from python3's immutable 'bytes' type
* GBytes can be safely used as keys in hash tables, and have
functions for doing so: g_bytes_hash, g_bytes_equal
* GByteArray is a mutable form of GBytes, and vice versa. There
are functions for converting from one to the other efficiently:
g_bytes_unref_to_array() and g_byte_array_free_to_bytes()
* Adds g_byte_array_new_take() to support above functions
https://bugzilla.gnome.org/show_bug.cgi?id=663291
Presumably, the rationale for not storing the endianness is that
GVariant is a recursive type system, and in a sane format, endianness
only needs to be stored once per blob of data (once per D-Bus message,
once per file on disk, etc.).
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=632049
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Ryan Lortie <desrt@desrt.ca>
The choice between g_variant_iter_next() and g_variant_iter_loop() is a
bit confusing for some people. Add a note to the documentation of
g_variant_iter_loop() to clarify that it should be avoided except in a
few specific cases.
