A C library hands back a pointer and a length. What's known so far. For a single-threaded call sequence the buffer is readable and valid until the next library call. No ownership transfer. What isn't known. Whether another handle, a callback or a background thread can invalidate it. Still an assumption.
A pointer to const bytes only rules out mutation through that one access path. It says nothing about lifetime, and the bytes can still change through another path. So keeping the library handle alive may be necessary and still not enough.
Option one. Copy into an owned Vec<u8> before any other call is allowed. The pointer and length have to describe a valid readable range for the whole copy, with no conflicting foreign write. Copying can't fix a pointer that was already bad.
Option two. A borrowed view, which has to block every call that could invalidate it for as long as the view lives. Tying the borrow to one handle only works if all invalidation goes through that handle. Shared global storage in the library means other handles matter too. Concurrent calls and reentrant callbacks belong on the same list.
I'm starting with the copy and writing down the foreign guarantees it still leans on. They stay assumptions until there's evidence from the C side.
