Bind API to convert from/to bytes to/from Variant

[zeenix]

Bind Variant::new_from_bytes & Variant::get_data_as_bytes().

Related: #113.

[sdroege]

Maybe also add the to_bytes() binding while you're at it? Then we keep it symmetric :)

[zeenix]

Maybe also add the to_bytes() binding while you're at it? Then we keep it symmetric :)

Yeah, i intend to. I just wanted to get early feedback for learning purposes. :)

[zeenix]

Maybe also add the to_bytes() binding while you're at it? Then we keep it symmetric :)

Done. I've not tested that one yet. I'll report it here once done.

[sdroege]

Done. I've not tested that one yet. I'll report it here once done.

Looks good to me as long as that can never return NULL :)

[zeenix]

Looks good to me as long as that can never return NULL :)

Actually it can. :(

If value is a fixed-sized value that was deserialised from a corrupted serialised container then NULL may be returned. In this case, the proper thing to do is typically to use the appropriate number of nul bytes in place of value . If value is not fixed-sized then NULL is never returned.

This is from docs of g_variant_get_data but g_variant_get_data_as_bytes docs say the semantics are identical.

[sdroege]

Actually it can. :(

Option it is then :)

[zeenix]

All done.

[GuillaumeGomez]

👍

[EPashkin]

From https://github.com/GNOME/glib/blob/mainline/glib/gvariant-core.c#L938 g_variant_get_data_as_bytes always return Bytes,
even in case NULL from g_variant_get_data
it doing something strange, but returns Bytes anyway.

[EPashkin]

@zeenix Sorry, I was wrong, g_bytes_new_from_bytes return NULL if it get wrong parameters, so Option is needed.
Thanks, 👍

[sdroege]

@zeenix Sorry, I was wrong, g_bytes_new_from_bytes return NULL if it get wrong parameters, so Option is needed.

When?

[EPashkin]

If bytes_data==NULL, then data - bytes_data=>data so g_bytes_new_from_bytes get pointer as offset parameter and it not pass check in https://github.com/GNOME/glib/blob/mainline/glib/gbytes.c#L227

[sdroege]

That's a g_return_val_if_fail(), those are basically like panics. Nothing we need to take into account (other than trying to not make it possible to call C API in ways that end up in there).

[zeenix]

I removed the Option.

[sdroege]

Nice

process didn't exit successfully: /home/travis/build/gtk-rs/glib/target/debug/deps/glib-b0a38ca36f7dfe57 (signal: 11, SIGSEGV: invalid memory reference)

On all nightly builds 🙈

[sdroege]

I can confirm, it's the subclass::object::test::test_create test that explodes. Unrelated to this PR though.

[sdroege]

Regression caused by rust-lang/rust@fc23a81, hm!

[sdroege]

rust-lang/rust#69102

[GuillaumeGomez]

Daily breaking changes time is back!

[sdroege]

Don't be so dramatic :) It's just a bug, and might even be one on our side that just happened to not trigger for a long long time.

[GuillaumeGomez]

My bad... I have memories from the past where every day was a whole new language haha.