up do date minibytes crate

[somethingelseentirely]

The minibytes sub-library is way too elegant and useful to be hidden away. It would be great if it was published regularly so that a recent version can just be pulled from crates.io.

[somethingelseentirely]

Just as an upgrade, I've decided to create a fork that tries to combine the best aspect of minibytes and ownedbytes called anybytes.

I've just discovered some UB in my library that I think also affects minibytes.
When a Bytes is created from a Vec<u8> as the ByteOwner, then the reference returned fromdowncast_mut might be reallocated when the Vector is resized. Since the pointer in the Bytes themselves is not invalidated it can result in a use after free situation.

I don't really need a recent minibytes release anymore, so feel free to close this issue.

Thank you so much for your work and take care!

[quark-zju]

Sorry for the late reply and thanks for spotting the UB! It seems we don't use downcast_mut outside minibytes itself. So perhaps we can just mark it as a private function.

[somethingelseentirely]

I think that would be an option, although the act of handing out a & and &mut at the same time alone is probably UB.
I changed the API to return an Arc<T>, where T is the type downcast to. That way you can only get mutability if all Bytes with that owner have been dropped.

[quark-zju]

handing out a & and &mut at the same time

Could you give an example about when that can happen? Given that:

• downcast_mut takes &mut self which means no as_ref() slices are handed out.
• The struct uses *const u8 instead of &'static [u8] (like ownerbytes) so there is no in-struct & and &mut being alive at the same time.

It's unclear to me how we have & &mut borrows both alive at the same time.

[somethingelseentirely]

Yeah I think you're right, sorry my bad!