Skip to content

#[serde(with = "serde_bytes")] does not work in no_std. #41

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

Closed
sosthene-nitrokey opened this issue Aug 28, 2023 · 1 comment · Fixed by #47
Closed

#[serde(with = "serde_bytes")] does not work in no_std. #41

sosthene-nitrokey opened this issue Aug 28, 2023 · 1 comment · Fixed by #47

Comments

@sosthene-nitrokey
Copy link
Contributor

Hi!

I stumbled around some confusing behaviour with regards to no_std builds:

use serde::{Deserialize, Serialize};

#[derive(Deserialize, Serialize)]
struct Testing<'a> {
    #[serde(with = "serde_bytes")]
    testing: &'a [u8],
}

Compiles if the std or alloc feature is enabled, but doesn't compile if it isn't.
I do not understand why the deserialize function is behind such a feature flag.

I understand that serde_bytes only changes the serialization of &[u8] since serde's implementation is already optimized, so you can get around the issue with

#[derive(Deserialize, Serialize)]
struct Testing<'a> {
    #[serde(serialize_with = "serde_bytes::serialize")]
    testing: &'a [u8],
}

But:

  1. That is counter intuitive, since the doc's main example uses #[serde(with = "serde_bytes")]
  2. It is more verbose
  3. I do not understand why this should be gated behind the requirement of an allocator.
  4. The error confusing since rustc can't understand the problem (though recent version do correctly point out the feature flag).

Can this feature-gate be removed?

Thanks

@sosthene-nitrokey
Copy link
Contributor Author

Fixed by #47

@dtolnay dtolnay linked a pull request Dec 27, 2023 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging a pull request may close this issue.

1 participant