msgpack-rust icon indicating copy to clipboard operation
msgpack-rust copied to clipboard

msgpack doesn't work with OsString

Open ajeetdsouza opened this issue 4 years ago • 2 comments

Take, for example, the following program:

use std::ffi::OsString;

fn main() {
    let data = OsString::from("qwerty");
    let serialized = rmp_serde::to_vec(&data).unwrap();
    let deserialized: OsString = rmp_serde::from_slice(&serialized).unwrap();
}

The resultant code compiles, but panics at runtime:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Syntax("invalid type: integer `0`, expected `Unix` or `Windows`")', src/libcore/result.rs:1188:5

The Serde data model does discuss the implementation of OsString.

My system configuration is as follows:

  • rustc 1.41.0
  • rmp-serde 0.14.3

ajeetdsouza avatar Feb 27 '20 16:02 ajeetdsouza

I believe this is more a bug in serde's enum handling interacting with the msgpack format than our processing. This is very similar to https://github.com/3Hren/msgpack-rust/issues/178 / https://github.com/serde-rs/serde/issues/1437.

Specifically, when deserializing "enum-like" things that aren't actually enums, serde only supports receiving u32, not all integer types. But msgpack serializes integers as the smallest type that they fit into, so enum variants are generally stored as u8 rather than u32 and thus deserialized as u8s.

Serde was fixed to accommodate this optimization for enums inside untagged context in https://github.com/serde-rs/serde/pull/1438, and at a first glance I think the best way forward for this issue would be a similar PR. It would need to modify the internal variant_identifier! macro to support u8 in addition to u32, and possibly also serde_derive's #[serde(variant_identifier)] option similarly if it suffers from the same problem.

daboross avatar Feb 28 '20 03:02 daboross

@ajeetdsouza @daboross https://github.com/serde-rs/serde/pull/1888 should fix this.

joshtriplett avatar Sep 12 '20 04:09 joshtriplett