Enable no_std support

[gendx]

In principle, lzma-rs doesn't have a long list of dependencies, and implements the core LZMA algorithm purely in Rust. Therefore, it could be made compatible with no_std build targets (at least when none of the dev dependencies/features are activated).

[glaeqen]

I don't think this is exactly trivial, especially assuming no_std and no_alloc approach. Lack of alloc would require changes to the API; more explicit memory provisioning. Currently, Vecs are used all over the place so algorithm can allocate as much memory as it wants at any point. Some of the Vecs of known length can be replaced with statically allocated heapless::Vecs or even regular arrays (putting aside const generics being still insufficient to nicely cover this in eg. BitTree). Additionaly, sometimes required memory depends on incoming headers/data, like eg. literal_probs which can be as large as 6+ MB. What's your take on it? Is alloc the only way to move forward without a complete redesign?

As for the rest, core2 crate provides the subset of std traits that are not available within core and are used by the project. Mostly std::io based ones. Dependencies are no_std either way. Strings in errors can be replaced with explicit enums and proper Display/Debug traits implementations. Allocations are the most problematic part.

[gendx]

What's your take on it? Is alloc the only way to move forward without a complete redesign?

Apologies for the delay in replying.

It may be worth redesigning the implementation somewhat, to better separate the parts of the APIs that allocate data (i.e. upon reading the headers), from the core of the algorithm (which could be passed a buffer externally).

Then, the no_std use cases could choose their allocating strategy: either depending on some alloc implementation, or passing a static buffer - potentially limiting the available memory to less than 6MB, with the core algorithm returning an OOM error if the buffer capacity is exceeded (in the spirit of #50).

This could also play nicely with things like #72, where a buffer could be passed along with the fixed parameters (although some validation would be required to ensure the buffer indeed has the correct size for the parameters).

Strings in errors can be replaced with explicit enums and proper Display/Debug traits implementations.

That's also on the radar with #6 :)

[Qix-]

Is there still an interest in this? Using LZMA in a no_std setting - even if it requires alloc - would be really helpful.

[glaeqen]

There's somewhat rushed but functioning heapless based lzma-rs if you need it (no alloc, no-std). But it's not exactly perfect. Library should be redesigned as @gendx suggests to do all of that in a saner way.