Wouldn't help in this case, the bugs are in things that Rust's type system doesn't help you with like references being held across processes that are sharing memory segments, connected to GCd JavaScript heaps. Affine types aren't able to express that stuff.
At least some of the issues here appear to be UAFs where raw pointers are taken to RC'd objects under the assumption that the object will not be freed while the raw pointer is held. That is not possible to express in Rust (without unsafe).
Some other issues are definitely going to be trickier - for example, passing a raw pointer to another context and then crashing that context while it's still held. This has come up within Rust before - how do you handle `&str` backed my mmap when another process could write to those values.
And then some are... maybes. Integer underflow panics in tests but not in release - when mixing it with something inherently unsafe like alloca, would Rust have helped? IDK. Certainly I think integer overflows are less likely to make it to release in Rust thanks to the default behavior, but it's also absolutely an area where I expect Rust to do only a bit better than other languages.
Cross-process shared memory doesn't really make a difference here. Rust's support for multithreading works the same way regardless, there's no expressivity problem.
x-process shared memory is definitely a problem. This has come up before - ex: is it safe to hold a &str into an mmap'd page? Another process could modify the data such that it is no longer valid utf8, even though you held a reference to it.
This is just out of scope for the borrow checker. Instead you'll have to roll your own abstraction that tries to maintain its own invariants, such as a &MmapStr that doesn't perform any `unsafe` operations that assume utf8/ immutability.
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.
The point of Rust's type system here is that it makes that distinction at all, not that the one side of that distinction has additional invariants.
> 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!
