alloc feature ?

[pwnorbitals]

Seeing the crate is no_std, I was tricked into thinking it wouldn’t depend on alloc and would work in my embedded system. A large chunk of embedded systems cannot use a heap for various reasons, so Ouroboros is not compatible with those systems right now.

In the short-term, I suggest adding a warning on the readme saying that, even though the crate is no_std, it still requires alloc to work.

In the longer term, is it viable to expose an alloc feature flag (could be default) that would make Ouroboros compatible with heap-less systems ?

[someguynamedjosh]

I have updated the readme to reflect this. Unfortunately, Box<> forms an integral part of the protections the crate provides, so I do not see a way to make the crate work without allocators.

[someguynamedjosh]

I will leave this open in case anyone has ideas of how to accomplish this.

[kpreid]

Some ideas:

• Perhaps in the future when allocator_api / std::alloc::Allocator is stable, it might be feasible to allow parameterizing an ouroboros object with that and thus allocate self-referential objects in fixed-maximum-size storage rather than the heap.

• With today's Rust: Use Pin. The non-movable memory would be inlined into the struct rather than a separate allocation, but initialization and access would require a Pin<&mut Self> or some such thing. Unlike the internal Boxes, this would be an externally visible requirement when constructing the object, but that is probably acceptable for no-allocator use cases.

  (I'd like to see a crate that provided safe self-referential structs based on Pin rather than boxing. I doubt extending ouroboros is the best way to do that, but it'd be interesting to have both strategies using as close to equivalent API as possible.)

[pwnorbitals]

From discussions today on Rust’s Matrix channel, sebk suggest it could be possible to use relative addressing into the struct to make stack-based self-referential structs work. Actual references would need to be re-computed somehow when user needs access to the values. Not sure how implementable this is, though

[pwnorbitals]

Related :

• https://users.rust-lang.org/t/relative-pointer-an-abstraction-to-build-movable-self-referential-types/26186
• https://docs.rs/rel-ptr/latest/rel_ptr/
• https://www.reddit.com/r/rust/comments/l4j823/relative_pointers_vs_pinning_for_self_referential/

It looks like it’s actually quite implementable !

[SoniEx2]

Shameless self-plug, could also try selfref? It hasn't been as thoroughly tested tho.