-
-
Notifications
You must be signed in to change notification settings - Fork 86
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
zvariant: Inconsistent serialization of varible key length dictionary contained within zvariant::Value
#868
Comments
That's very strange. 🤔 The encoding of both should be exactly the same. I'm afraid I won't have the time to investigate and fix this anytime soon. PRs welcome of course. |
felinira
added a commit
to felinira/zbus
that referenced
this issue
Jun 27, 2024
Adds a test for serializing dictionaries from zvariant::Value in contrast to using zvariant::SerializeValue directly. Reproduces issue dbus2#868.
felinira
added a commit
to felinira/zbus
that referenced
this issue
Jun 27, 2024
Dictionaries with variable length keys require a framing offset. The SerializeMap implementation already handles this, the manual serialization of dict entries used by Value does not. We now call directly into SerializeMap when serializing Value to align these serializations. Closes dbus2#868
felinira
added a commit
to felinira/zbus
that referenced
this issue
Jun 27, 2024
Adds a test for serializing dictionaries from zvariant::Value in contrast to using zvariant::SerializeValue directly. Reproduces issue dbus2#868.
felinira
added a commit
to felinira/zbus
that referenced
this issue
Jun 27, 2024
Dictionaries with variable length keys require a framing offset. The SerializeMap implementation already handles this, the manual serialization of dict entries used by Value does not. We now call directly into SerializeMap when serializing Value to align these serializations. Closes dbus2#868
felinira
added a commit
to felinira/zbus
that referenced
this issue
Jun 27, 2024
Adds a test for serializing dictionaries from zvariant::Value in contrast to using zvariant::SerializeValue directly. Reproduces issue dbus2#868.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The following test code uses glib-rs to construct a VARIANT type gvariant with
glib::Variant::from_variant
and the same variant with zvariant::Value in gvariant mode.This is a byte comparison of the serialisation. Left is glib, right is zvariant:
It looks like zvariant does not encode the key framing offset, while glib does. https://developer.gnome.org/documentation/specifications/gvariant-specification-1.0.html#dictionary-entries.
glib will look for the framing offset, read the dict entry offset instead, and then fail to parse the entry correctly.
This is a comparison of
glib::Variant::print
on these variants, for completion sake:Replacing
zvariant::Value::new
withzvariant::SerializeValue
fixes the serialisation issue. However this is not always possible, especially when having to store variants in unserialized form, or when nesting variants.The text was updated successfully, but these errors were encountered: