[Rust] Support no_std environments without `alloc`
I'm working on some rust firmware and we are considering the use of flatbuffers. I know that the official flatc requires alloc. However, we are looking to target devices that don't have enough flash space for that, since they cost less.
Is there any plan on adding support for something like heapless::Vec or using a &mut [u8] as a buffer instead of a Vec? Its a bit of a stretch but I thought I would ask.
I think it is a similar issue to https://github.com/google/flatbuffers/issues/7618 and https://github.com/google/flatbuffers/issues/7765
This is a thing we want and others have tried, but there are no current efforts for this
What level of breaking change is acceptable to implement this? It will certainly be a breaking change.
Ideally, the minimum amount - we can expect users to regenerate code but they should not have to change the code they themselves wrote. What kind of breaking changes are you planning?
I think we need to parameterize the FlatBufferBuilder with a new public trait that encapsulates the Vec<u8> we build the flatbuffer in. Libraries can implement this trait for (a newtype wrapper over) heapless::Vec<u8, MAX_SIZE> and then export something like the following
pub type FlatBufferBuilder = FlatBufferBuilderWithCustomStorage<Vec<u8>>;
If you want to change push to accommodate hitting the MAX_SIZE, we can add new try_push methods with result types.
This issue is stale because it has been open 6 months with no activity. Please comment or label not-stale, or this will be closed in 14 days.
not stale
This issue is stale because it has been open 6 months with no activity. Please comment or label not-stale, or this will be closed in 14 days.
not stale
Fyi, if I remember correctly, the C++ version uses the flatbuffers "custom" allocator in order to embed information about the fields while constructing the flatbuffer. I ported the Allocator trait to Rust and I might eventually get to working on this change. I do have a patch downstream that replaces Vecs with the heapless alternative for now but I don't want to upstream that since it's not really the solution I think would be most useful