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

no_std support (with default-enabled "std" cargo feature) #255

Closed
wants to merge 1 commit into from

Conversation

tarcieri
Copy link

@tarcieri tarcieri commented Apr 14, 2019

This PR revives #135 now that the alloc crate is stable, which unlocks using bytes in embedded RTOS environments or other embedded environments with enough RAM to warrant a heap (e.g. on SAMD51 uCs that have 192kB RAM).

Like the original #135 actual alloc support will be added in a subsequent PR, and this is a first pass to add initial no_std support and sanity check the approach.

In absence of upstream support for this, I've had to create forks of bytes and forks of downstream consumers of bytes, so it'd be really swell to get this all upstream rather than forking!

@tarcieri tarcieri force-pushed the no_std branch 2 times, most recently from 621104f to a10eb40 Compare April 14, 2019 15:09
Feature gates anything dependent on `std` on the eponymous cargo
feature, and changes references to libcore features from `std` to `core`
@tarcieri
Copy link
Author

Note: I'd also be happy to pursue this on the 0.5.x branch only, as I think there are some opportunities there to address other tough problems like the pervasive use of io::Cursor

@tarcieri
Copy link
Author

tarcieri commented Sep 5, 2019

Obsoleted by #281

@tarcieri tarcieri closed this Sep 5, 2019
@tarcieri tarcieri deleted the no_std branch September 5, 2019 21:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant