Jett Rink

This miri issue appears to be more related to casting [dynamically sized types][0] than it does with casting `u8` to `Cell`. The way that the process buffer code is written,...

This following unit test does not complain about any miri unsoundness: ```rust #[cfg(test)] mod test { use super::*; #[test] fn test_convert() { let array: [u8; 10] = [1; 10]; let...

Ah, thank you. I missed that. This means that we just really need to make `ReadableProcessByte`'s `cell` field a real `u8` instead of a `Cell`. We are actually opening the...

Ah, thank you Leon for that in depth response/discussion! You bring up a good point why we can't use `u8` directly since we would be breaking the aliasing rules. I...

Well `MaybeUninit` tells rust that the memory might not be initialized, so it can't perform many optimizations. Also we access it though unsafe raw pointer reads which won't get optimized...

I think this UB issue exists whether or not we allow the kernel to convert `&[u8]` into a `ReadableProcessSlice` or not. A rust application can and does pass `&[u8]` buffers...

I am still having trouble understanding why this is only a problem for the kernel. If we have an application that shares a reference to a `const DATA: [u8;10] =...

Can we not cast the kernel's `&[u8]` reference to a pointer to "wash away knowledge" then turn it into a `ProcessBufferSlice` similar to the application flow? If that doesn't work...

> It's only detectable in the kernel ... [The App version] is the same issue, and I would call it UB from the perspective of Rust's memory model It sound...

I don't know how much it is worth going back and forth on this because hopefully we can address the real kernel issue and the potential phantom app issue with...