ReadableProcessBuffer should be sealed or unsafe trait

[kupiakos]

In order for unsafe code working with generic ReadableProcessBuffer (and WriteableProcessBuffer with #3756 implemented) to trust that their implementations of ptr to be correct, that code needs to either:

• Constrain implementations to a fixed and auditable set of ReadableProcessBuffer types, or
• Have an unsafe guarantee from trait implementers that the ptr method returns a pointer with the documented requirements.

See How Safe and Unsafe Interact for more info on when unsafe trait is needed.

[kupiakos]

Note: #![forbid(unsafe_code)] can generally interact with and use an unsafe trait without issue; it primarily affects implementers of the trait itself.

[alevy]

This seems right to me. In other words, the implementations of ReadProcessBuffer has to be trusted even if it doesn't happen to require unsafe to write. So marking the trait unsafe would help ensure that only trusted code is allowed to write this trusted code.

[kupiakos]

Yes, at the moment any implementer of ReadableProcessBuffer could write fn ptr(&self) -> *const u8 { ptr::null() }. Since there's no safety requirement for trait implementers, that implementation is fine according to soundness rules - thus it's not fine for unsafe code to trust generic ReadableProcessBuffer::ptr output to be a valid pointer.