2 ms·
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 co
by haberman 9y ago
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-untrusted-modules-at-api-level/1505/9 https://internals.rust-lang.org/t/safe-rust-sandboxing-untru...
On the other hand, maybe this role is better served by WebAssembly.
- gpm 9y agoRaising 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%3Aissue+label%3AI-unsound https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Ais...
- zzzcpan 9y agoI'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.