Hacker News Reader

Comment by pcwalton | Hacker News Reader

You can't prove safety properties of something that isn't safe. LLVM IR sure isn't.

This raises an interesting question of whether Rust would make sense as a code generation target for other languages or runtimes. It is conceivable that you could compile and run untrusted Rust (with no unsafe blocks and restricted imports) the same way web browsers run untrusted JavaScript? It could be the only GC-less IR that you can run with a reasonable defense against memory corruption.

Looks like people have had this idea before: https://internals.rust-lang.org/t/safe-rust-sandboxing-untru...

On the other hand, maybe this role is better served by WebAssembly.

I'm not sure I understand your idea, how can code generation benefit from memory safe abstractions of target languages? The whole point of code generation or rather compilation is to fit one representation into something else, doesn't matter what it is, but it has to satisfy its constraints no matter what, even if you have to use a giant global array to emulate pointers via indexes. In other words, the goal is to work around any constraints of the target language to fit yours, but not to design your language to fit any constraints of the target.

Safety guarantees can only work if you carefully choose and rely on appropriate abstractions for your problem.

Raising logic bugs from "this is maybe occasionally an annoyance, or cool piece of trivia" to "this is a security issue" seems like a bad idea in something as complex as Rust's compiler.

Especially when there are many currently known bugs of this sort:

https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Ais...

Verification of unsafe languages such as unsafe Rust (here), or C, PHP or assembly (in other research) tries to show if some particular program is correct or not — by exhibiting bugs, proving safety, or both. Tons of approaches exist.

But verification can be easier for higher-level languages.

Reply on news.ycombinator.com