#![no_std] support

[mooman219]

Are there plans to push for #![no_std] support in the future, specifically core + alloc + libm?

By the looks of it, there are a couple of std calls that for the most part have a 1:1 conversion, but path, file, and IO operations usually don't. Only including those via a flag would fill that gap.

[pdeljanov]

It's a good idea and I'd support it if someone wants to take on the task, but I don't think it's something I'd take on for a long while.

There would also be some off-shoot work required to make Symphonia more viable for things like embedded targets. Things like optimizing bit IO for 32-bit machines, lowering memory usage, implementing more optimizations, etc.

[mooman219]

I think I have time to put together some PRs to start the equivalent std -> core conversions. Changes after that would be marking off API that can't be converted as requiring std, and including that as a default feature flag as to minimize breaking changes to the API.

There will need to be some major work reworking io::Error and std:error. Do you have any opinions on that before I take a crack at it?

[pdeljanov]

Hi @mooman219,

I probably should've read this before looking at your first PR.

I don't have any experience writing a no_std library so unfortunately I can't offer any solid advice or direction. I'd need to survey what other crates are doing first before I can form an opinion. Or, if you have some ideas or know what the best practice is, we can discuss them.

I do have a couple general thoughts based on the research I've done since reading your message.

1. I think we can work around the lack of std::io fairly easily. Symphonia relies on its own IO traits (e.g., ReadBytes), so filling in the gaps should be pretty simple albeit with some refactoring.

2. The larger challenge will be the lack of a std::error::Error. I don't currently have any ideas for this. Perhaps there's a crate that can cover it for us? However, for default/std-enabled builds, I think we want to continue using std::error::Error for consistency with the rest of the ecosystem. More generally, I don't want to add any complexity to default/std-enabled users since I do believe they will be the vast majority.

Going forward, perhaps we should merge any PRs into a new branch since these changes may take some time to land and settle. Alternatively, could also just push all the commits to the PR branch and merge when it's time.

[mooman219]

Seems sensible, the io/error related changes are the biggest pain. There's the core2 crate which explores the situation. There are also a couple of RFCs that try to address this issue, but they're quite old.

The history here is that most of IO could be in core, but the error type couldn't be represented without an allocation, which at the time was more complicated to represent in core, so everything was left in std.

[pdeljanov]

Hi @mooman219,

Apologies for being inactive on this. Unfortunately, I don't think I'll be able to help much on this until after I release v0.5. There are a number of time consuming issues to resolve for that release that I still need to address.

I did poke around a little bit though, and the snafu library looks interesting. I didn't play around with it, but I did see it being used in some other no_std libraries. So it may be worthwhile investigating. The core2 crate doesn't seem to have much traction so I'd be a bit hesitant to go that route.

[mooman219]

I personally don't think the io:Error's boxed custom error type is useful in general. It's incredibly specific (and usually per platform) to respond to, and the associated ErrorKind is usually more than sufficient.

[mooman219]

There's good news! https://github.com/rust-lang/rust/pull/99917/ error::Error was moved into core/alloc! This is looks really hopeful to me for io::Error landing in core, and maybe more of io::* in general getting moved in the future.