While working on postcard-rpc I noticed that all APIs assume that we work with slices.
However buffers are often created on the stack or in some pool, where the initial value is MaybeUninit::uninit(), and then we initialize the uninitialized data only to later again overwrite it.
Or we first crate a local array on the stack that is initialized, fill it, and the copy it into a channel or pool for shipment.
This is a solved problem in std land, e.g. in tokio::net::xSocket that have buffered operations (e.g. https://docs.rs/tokio/latest/tokio/net/struct.TcpStream.html#method.try_read_buf ).
Checking the underlying trait that is used, bytes, it seems like it would be straight forward to add support for this instead of reinventing the wheel like an old PR of mine here for MaybeUninit support.
What are your thoughts? Would it be worth implementing?
Another PR to heapless would also be needed, but it also looks simple to do.
Hi!
While working on
postcard-rpcI noticed that all APIs assume that we work with slices. However buffers are often created on the stack or in some pool, where the initial value isMaybeUninit::uninit(), and then we initialize the uninitialized data only to later again overwrite it. Or we first crate a local array on the stack that is initialized, fill it, and the copy it into a channel or pool for shipment.This is a solved problem in
stdland, e.g. intokio::net::xSocketthat have buffered operations (e.g. https://docs.rs/tokio/latest/tokio/net/struct.TcpStream.html#method.try_read_buf ). Checking the underlying trait that is used,bytes, it seems like it would be straight forward to add support for this instead of reinventing the wheel like an old PR of mine here forMaybeUninitsupport.What are your thoughts? Would it be worth implementing? Another PR to
heaplesswould also be needed, but it also looks simple to do.BR Emil