support for no_std environments

[vitiral]

I came across this protocol and it looks absolutely perfect for microcontrollers! I understand some features support dynamically sized types, so cannot be supported on the stack, but was wondering if a subset of this library could support no_std?

If it is possible, but would have to be a separate crate then that would also be useful to know.

Thanks!

[vitiral]

I looked through the library, and I THINK std could be replaced with core except for the use of Rc in a few lines in is_canonical on the ReaderSegments struct. This struct instantiates the Rc and never returns it (but passes it by reference to lower functions) so I THINK it should be possible to implement a StackRc that is stored on the stack instead of the heap. If we did that, this library could be no_std! (it would also probably be a minor performance win).

[vitiral]

nevermind -- I just did a first attempt and after replacing all std instances with core I get 1898 lines of errors complaining about all the uses of Box, Vec and io::Reader. Obviously none of which are in core.

[dwrensha]

Indeed, we don't actually need Rc: 8200dbf

[dwrensha]

I would be interested in making capnproto-rust more embedded-friendly.

I know that @cmr looked into this at some point.

[vitiral]

I'm looking at it again... alot of the uses of Vec are lines like this:

let hooks: &Vec<Option<Box<ClientHook>>> = unsafe { &*hooks }

There are some cases like this:

let mut bytes : Vec<u8> = iter::repeat(0u8).take(packed.len()).collect();
let mut owned_space: Vec<Word> = Word::allocate_zeroed_vec(total_words);

It's possible some of those can be removed.

Here's the deal: for my use case (microcontrollers) I'm not really interested in dynamically sized payloads. I care about structs, nested structs, and arrays of a known size. Maybe I should just write a macro wrapper around bitflags and byteorder to get the ultra light serialization/deserialization I need. This lib feels too heavy handed.

[ishitatsuyuki]

Can you reopen this so people can easier see this?

[ProfFan]

From rust-lang/rfcs#2480 I see a possibility that Vec and Boxs will be coming to no_std. Please go support this RFC if you have time :)

[ishitatsuyuki]

@ProfFan That still requires an allocator which is not implemented on all platforms. Cap'n Proto should be able to handle reads without any dynamic allocation.

[ProfFan]

@ishitatsuyuki Indeed it is the best to have pure static reads, however if this RFC passed, you can port the alloc crate with a few lines of code on virtually every platform.

[ghost]

@dwrensha Is this under active development?

I would like to use capnproto-rust in wasm modules and it would help binary size by at least an order of magnitude to use no_std.

[dwrensha]

I don't know of anyone actively working on this. I agree that it would be good to have!

[snakehand]

Vec and Box are available in the alloc crate, and it might be a good start to make it possible to build for no_std + alloc environments.

[novacrazy]

How goes progress on this issue?

I'd love to use Cap'n Proto in WASM for an evolving but efficient API.

[dwrensha]

I've opened a pull request: #184.

[dwrensha]

#184 has landed.