> You can cause the same problems from another thread in the same process, or even from the same thread. The fact that an OS process boundary is involved isn't relevant- you simply don't form the &str if some other part of the system has that kind of access to it, whether or not the OS is involved.
No you can't, not without unsafe. Rust will not let you.
Again, this is sort of an up in the air discussion. In most cases saying "your type system can't handle someone else ptrace'ing you" is obvious and fine, but when you're talking about certain abstractions like mmap, where multi-processing and shared contexts are inherent, it's important to note that you can't just rely on normal aliasing rules.
My point is that you can solve the inter-process case with precisely the same tools that Rust already uses to solve the intra-process cases.
Outside of a pure-Rust single-threaded process that uses only stack allocation, those cases are already using unsafe- for heap allocation, or to launch a thread, or whatever. Or if Rust is a guest in some other language's process, you don't even need unsafe! And the type system features used to contain that unsafe are just as useful when you're sharing memory with another process as when you're sharing memory with another thread.
I'm obviously not saying you can just take a shared reference to an arbitrary mmapped buffer, or whatever. I'm saying that nvm0n2's claim is misleading, because Rust's type system does give you the tools for cases like this, at least to a greater degree than C++'s type system!
No you can't, not without unsafe. Rust will not let you.
Again, this is sort of an up in the air discussion. In most cases saying "your type system can't handle someone else ptrace'ing you" is obvious and fine, but when you're talking about certain abstractions like mmap, where multi-processing and shared contexts are inherent, it's important to note that you can't just rely on normal aliasing rules.