consider support for no_std

[NickeZ]

Would you consider putting the bits that require std behind a feature flag?

Thanks for a great crate.

[ia0]

Thanks for the suggestion! This is indeed something I had planned to do but never started because I didn't know if it would be useful to anyone.

Do you have any time constraint regarding this feature? Without any particular constraint, I'll try to look into it before the end of the year. But I could prioritize if necessary.

[NickeZ]

Thanks! I took a quick look and it seems like you have some Strings and Cow::borroweds which are not trivial to get rid of. Otherwise it seems like just dropping in use core as std will work. Looking forward to no_std support!

[ia0]

Cool! Thanks for having looked into it. I guess the no-std feature is going to change the API a bit. The 2 things I would see (according to your findings) are:

1. Don't use String, only u8 buffers.
2. Don't support creation of encodings at runtime.

I guess the first point is not an issue. For the second, I'm assuming no-std crates won't generate encodings at runtime but instead create them at compile-time.

[NickeZ]

I guess the first point is not an issue. For the second, I'm assuming no-std crates won't generate encodings at runtime but instead create them at compile-time.

1. Yeah, that is the common modus operandi in the world of embedded. We tend to use mostly stack allocated buffers.
2. It depends. Could you create them without heap allocation? I mean normally you simply put structs on the stack. In the end I think you are right and the most common use cases is to create them at compile time anyway.

Many embedded systems, like the one I compile for (cortex-m4), actually have a heap but are still no_std due to missing file-system support and so on. I'm not 100% sure how, but you could use the alloc crate to still use Strings and Cow::borroweds. Maybe that is a good initial goal? That would actually allow me to use your crate.

Thanks again!

[ia0]

Hi @NickeZ,

I've written #31 to add an std (which is the default and implies alloc) and an alloc feature to the data-encoding crate. If you would have the time to test (or even review) the PR before I commit it, I would greatly appreciate. But I would understand if you don't have the time. I'll commit in 2 weeks otherwise and probably release before the end of the year.

You can test the PR by changing the data-encoding dependency in your Cargo.toml with:

[dependencies.data-encoding]
git = "https://github.com/ia0/data-encoding"
branch = "nostd"
default-features = false
features = ["alloc"]  # Omit this line if you don't have an allocator.

Thanks! Julien