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

[WIP] no_std support #339

Closed
wants to merge 2 commits into from
Closed

[WIP] no_std support #339

wants to merge 2 commits into from

Conversation

@VictorKoenders
Copy link

VictorKoenders commented Jun 26, 2020

Started working on no_std support

⚠️ This is a breaking change ⚠️

This PR adds 3 new features:

  • std (enabled by default)
  • alloc has no std support, but does support strings, collections and boxes
  • no features, no_std. This disables all allocations and OS-specific code.

The changes in this PR are: (unchecked features are not final)

  • std::io::Read/Write doesn't exist in core (tracking issue) This is solved by implementing our own Read/Write traits
  • std::io::Error and std::error::Error are also not available. We create our own io error type, and we explicitly implement serde::de::Error when we're in no_std mode
  • byteorder::ReadBytesExt and byteorder::WriteBytesExt are not available outside of std mode. (Related issue that states that they're waiting on RFC 2262)
… alloc and no_std by features
@Plecra
Copy link

Plecra commented Jun 26, 2020

I think there's a much better solution for us to find before taking this route. Maintaining three versions of the primitives the library uses is asking for subtle, annoying bugs to track down. And we'd also be forcing that inconvenience on users - they'd have to deal with an Error type that didn't actually implement 90% of the documented API.

We floated the idea of a separate crate for the no_std implementation, which would also give us a chance to clean up the API. It doesn't need to have anything to do with std::io if we use an associated error type in a trait akin to serde_json::de::Read.

@ZoeyR
Copy link
Collaborator

ZoeyR commented Jun 26, 2020

Yeah, I would be interested in making a bincode_core crate, beraking whatever you want in that. And reshimming it to match the bincode api from the bincode crate.

@VictorKoenders
Copy link
Author

VictorKoenders commented Jul 13, 2020

Zoey and I started work on bincode-core here: https://github.com/bincode-org/bincode-core

Closing this PR in favor of that

@VictorKoenders VictorKoenders deleted the VictorKoenders:no_std branch Jul 13, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

3 participants
You can’t perform that action at this time.