Rust: add support for no_std env

[overcat]

Enable rs-stellar-xdr to encode/decode XDR in a no_std environment.

See stellar/rs-stellar-xdr#392

[overcat]

I did not modify the relevant code, so I am not sure why clippy is giving a warning. And I encountered some difficulties in fixing this warning, so let's add it first.

[leighmcculloch]

Thanks for looking into this.

Why embedded-io over core_io? Are there other crates to consider? I haven't looked into this enough yet to know myself, but core_io is more of a mirror of std::io, and it has a Cursor type.

I noticed that we're using embedded_io_extras to get a Cursor type. Do you think that could be contributed upstream to reduce the nested dependencies we're adding to the xdr lib? I also wonder if embedded-hal has an equivalent type we're missing.

Rather than add a generic sounding 'alloc' feature to the stellar-xdr crate, I'm inclined to instead add a feature named after the optional dependency. So if you enable the embedded-io feature, you get embedded-io capability.

We need to think about how to test this for consistency with the std::io behavior. The xdr lib depends on the std::io::Read::read_exact function, and it's default_read_exact implementation, and it has some subtle interactions with reading EOF safeties in the xdr lib. But I notice that the embedded-io read_exact function isn't identical, and so I think we'll be hesitant to merge changes unless we can either avoid the difference, or do some differential fuzzing to ensure there's no breakage or observable difference in behavior.

[overcat]

Hi @leighmcculloch, thank you for taking the time to review the PR.

Why embedded-io over core_io? Are there other crates to consider? I haven't looked into this enough yet to know myself, but core_io is more of a mirror of std::io, and it has a Cursor type.

I researched the following libraries:

• ciborium_io: Only provides Read/Write traits and differs significantly from std::io::Read/Write.
• core2: Offers an API almost identical to std::io, but hasn't been maintained for over two years. I'm concerned about the project's future. [WIP] Rust: add support for no_std env #204 includes an implementation using core2.
• core_io: Last released in 2021 with very few downloads.
• embedded-io: Maintained by rust-embedded, actively developed. I believe it's currently the best choice.

I noticed that we're using embedded_io_extras to get a Cursor type. Do you think that could be contributed upstream to reduce the nested dependencies we're adding to the xdr lib? I also wonder if embedded-hal has an equivalent type we're missing.

I will create an issue to ask if they would consider adding Cursor to embedded-io. Another option is to implement Cursor in rs-stellar-xdr, allowing us to depend directly on embedded-io. I think Cursor does not exist in embedded-hal.

Rather than add a generic sounding 'alloc' feature to the stellar-xdr crate, I'm inclined to instead add a feature named after the optional dependency. So if you enable the embedded-io feature, you get embedded-io capability.

I like this idea, so that embedded-io will only be used when the user explicitly enables it.

We need to think about how to test this for consistency with the std::io behavior. The xdr lib depends on the std::io::Read::read_exact function, and it's default_read_exact implementation, and it has some subtle interactions with reading EOF safeties in the xdr lib. But I notice that the embedded-io read_exact function isn't identical, and so I think we'll be hesitant to merge changes unless we can either avoid the difference, or do some differential fuzzing to ensure there's no breakage or observable difference in behavior.

I need to do a bit more research. If I have any questions, can I reach out to you on Discord?

[overcat]

rust-embedded/embedded-hal#631

[overcat]

I added some tests to verify whether the behavior of embedde io meets expectations.