Skip to content
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

Make it easier to write cross-platform code with serde #1594

Closed
cbeck88 opened this issue Aug 1, 2019 · 4 comments
Closed

Make it easier to write cross-platform code with serde #1594

cbeck88 opened this issue Aug 1, 2019 · 4 comments

Comments

@cbeck88
Copy link

cbeck88 commented Aug 1, 2019

Right now serde supports no_std in that it has an std feature, and an alloc feature, and it supports having neither of them turned on.

But, if std and alloc feature are both used, it usually causes build failures.

This is because there is an interface change at the following lines:

#[cfg(feature = "std")]
declare_error_trait!(Error: Sized + error::Error);

#[cfg(not(feature = "std"))]
declare_error_trait!(Error: Sized + Debug + Display);

My use case is that I am working on servers that contain SGX enclaves. The server (untrusted) part can use std because it has the OS available, but the enclave (trusted) part, cannot use std, because there is no trusted OS inside the enclave.

In principle, it should be very convenient to use serde to pass messages between the server and the enclave, because it avoids adding more build steps for serialization, and ensures a single-source-of-truth for the serialization schema. And there's no reason that serde should not work in the enclave.

(There is the issue of std::collections::HashMap not being available outside of std but this is not a problem.)

The real problem is that std::error::Error does not exist in core, because the devs have declined to move it there.

An alternate solution is to use the failure crate instead of std::error module, which provides the same functionality with some improvements, and without requiring std.

It would also be great if there were a way to use serde so that the interface does not break between std and alloc settings. Why use std::error at all? Can we just use Debug + Display in all cases?

The current case basically means that anyone who wants to use serde in a cross-platform crate that works with both std and nostd contexts, must expose std and alloc features mirroring serde, and if these features get confused at any point, the build fails in strange ways.

It would be a lot simpler to write cross platform code if, code that doesn't need std can simply omit std, and then be used as a dependency of code that does need serde/std (for example to serialize a hash map), without causing a build failure within serde. This would prevent serde dependency from infecting the entire project with std and alloc feature flags.

Is there any interest from developers in reconciling the differences between these two lines?


#[cfg(feature = "std")]
declare_error_trait!(Error: Sized + error::Error);

#[cfg(not(feature = "std"))]
declare_error_trait!(Error: Sized + Debug + Display);

I am strongly considering patching serde in my project to always use the Debug + Display version even when std is on, because I think all my dependencies will still work fine -- the error::Error trait is mostly useless.

@cbeck88
Copy link
Author

cbeck88 commented Aug 1, 2019

@cbeck88
Copy link
Author

cbeck88 commented Aug 1, 2019

I realized this is basically a repost of this: #1567

@cbeck88
Copy link
Author

cbeck88 commented Aug 2, 2019

I guess this might be mooted if the lang team does this? rust-lang/rust#62502

@dtolnay
Copy link
Member

dtolnay commented Nov 24, 2019

I believe this is fixed with the reexports in 1.0.100:
https://github.com/serde-rs/serde/releases/tag/v1.0.100

Data formats can provide the right Error impl whether or not Serde is built with "std" by writing:

impl serde::ser::StdError for MySerError {}

impl serde::de::StdError for MyDeError {}

@dtolnay dtolnay closed this as completed Nov 24, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants