[glib] In the GVariant intro, mention lack of built-in endianness, and rationale



commit 7973d9f8bac34fa090e330dec136b251f305d06c
Author: Simon McVittie <simon mcvittie collabora co uk>
Date:   Mon Oct 3 14:27:15 2011 +0100

    In the GVariant intro, mention lack of built-in endianness, and rationale
    
    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>

 glib/gvariant.c |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)
---
diff --git a/glib/gvariant.c b/glib/gvariant.c
index 89b7ec3..2661e0d 100644
--- a/glib/gvariant.c
+++ b/glib/gvariant.c
@@ -72,6 +72,14 @@
  * as the serialisation format of a D-Bus message body: use #GDBusMessage,
  * in the gio library, for those.)
  *
+ * For space-efficiency, the #GVariant serialisation format does not
+ * automatically include the variant's type or endianness, which must
+ * either be implied from context (such as knowledge that a particular
+ * file format always contains a little-endian %G_VARIANT_TYPE_VARIANT)
+ * or supplied out-of-band (for instance, a type and/or endianness
+ * indicator could be placed at the beginning of a file, network message
+ * or network stream).
+ *
  * For convenience to C programmers, #GVariant features powerful
  * varargs-based value construction and destruction.  This feature is
  * designed to be embedded in other libraries.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]