On 1/13/12 10:39 AM, David Bruant wrote:
It is my understanding that Rust is being designed also for the purpose of being safer than C/C++ [4]. Tell me if I'm wrong, but if a component is used as a library, it doesn't make it safer, yet, with privilege escalation, it makes the program that uses it as a library potentially vulnerable.
In order to actually take advantage of the safety features of Rust, such a compiler would have to convert code written in a memory-unsafe programming language to memory-safe code. Essentially, it would have prove through some combination of static and dynamic checks that the C/C++ code is memory-safe before translating it into the safe dialect of Rust. But there's a problem with this -- once you've proved that some C/C++ code is memory safe, you won't gain much by translating it into Rust. In particular, you've already proved all the static safety properties on your own that Rust's type system enforces. You had to have done so, or else the Rust code you generated wouldn't compile.
You might benefit from the dynamic safety properties, most notably (a) stack growth checks and (b) array bounds checks. But both of these have simpler solutions available. Stack growth checks are an LLVM feature, not a Rust feature: you can get them in C/C++ by simply using clang and enabling segmented stacks at the LLVM level. (You will have to provide an implementation of __morestack, but this is several orders of magnitude less effort than writing a C++-to-Rust compiler.) And array bounds checks can be achieved by simply using <vector> and std::vector::at(). If your goal is to get runtime array bounds checking, a static analysis tool for C/C++ to enforce consistent use of the STL and the safe accessors like std::vector::at() would be far easier.
Patrick _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
