Open zeenix opened 3 years ago
In GitLab by @bilelmoussaoui on Oct 24, 2020, 04:19
while not completely related, it would be nice to have Type implemented for std::ffi::CString
as well. I had a bunch of null terminated strings on some dbus calls that I had to add my own wrapper for now
while not completely related, it would be nice to have Type implemented for
std::ffi::CString
as well.
Right, see also this TODO comment. Since you already implemented Type
for it, perhaps it'd be a trivial contribution?
I had a bunch of null terminated strings on some dbus calls that I had to add my own wrapper for now
All D-Bus strings are null-terminated and our (de)serializer takes care of that for you so I'm a bit curious as to why you needed to take care of null termination yourself.:thinking:
In GitLab by @bilelmoussaoui on Oct 24, 2020, 21:12
I had a bunch of portals methods calls that took a null terminated string (while others didn't?) and I was a broken thing until I added a NString, that wraps CString & implements Type for it
I had a bunch of portals methods calls that took a null terminated string (while others didn't?)
That seems like a bug in the portal implementation then. If the type of the data is s
, it must be null-terminated cause otherwise you're breaking the spec. It says:
UTF-8 string (must be valid UTF-8). Must be nul terminated and contain no other nul bytes.
but that's on the D-Bus level. The Rust's String
and str
types are not null-terminated so zvariant adds the null-byte during serialization and removes it during deserialization for you. In any case, user shouldn't have to care.
First candidates would be
url::Url
anduuid::Uuid
. Some of them are here.