[rust-dev] Student projects/internships

Patrick Walton pwalton at mozilla.com
Fri Jan 13 10:54:21 PST 2012

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.


More information about the Rust-dev mailing list