Hacker News Reader

Comment by crb002 | Hacker News Reader

Do this at the LLVM level and you get way more languages for free.

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.

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...

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.

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.

You've lost most of the semantics by the time you're at LLVM bitcode, since the high-level abstractions have been lowered into a basic for.

Rust's type system provides memory and race safety, but those details are lost at a lower level. It's very hard to analyze data races at the assembly level!

Reply on news.ycombinator.com