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 #1

Closed
perlindgren opened this issue Dec 4, 2020 · 3 comments · Fixed by #2
Closed

no_std support #1

perlindgren opened this issue Dec 4, 2020 · 3 comments · Fixed by #2

Comments

@perlindgren
Copy link
Contributor

Hi Helgoboss

I came across your crate while looking to implement support for usb-midi in no_std context. Your crate looks great, and I think it could be very usable also for embedded applications. I tried to strip it from std dependencies, but there is no core::error (rust-lang/rust#33149).

So what's your take on this?

(There are some other crates for midi with no_std support, but none seems as elegant as yours.)

Best regards
Per Lindgren

@helgoboss
Copy link
Owner

Hi Per, glad you stumbled upon this crate and find it useful :) I would be happy to make this usable in a no_std context. Is the lack of core::error the only blocker you ran into?

I'm open to alternatives concerning the error types. Do you have any idea how this is usually handled in no_std crates? I just followed the rigorously the Rust API Guidelines (I think this in particular), therefore the current code.

@perlindgren
Copy link
Contributor Author

Hi
I made a PR. There were a few dependencies that needed attention, but I got it to compile.

The main difference is that the newtype::new cannot use format! (I left the original code there commented out).

Especially in a no_std environment, "assert -> panic" is a bit problematic, perhaps new could return an Option (or even a Result). In any case the error is not local to new but rather a usage fault (you are trying to construct an illegal type).

Later one could think of a no_std (or std) as a feature, if you think there are some limitations to the no-default-features restriction on num_enum.

To be fair, I never used the core-error crate before, maybe there are other (better) options.

The tests pass, so I think you should be able to merge it as is.

/Per

@helgoboss
Copy link
Owner

Amazing, thanks for the PR. Will look into it.

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 a pull request may close this issue.

2 participants