[rust-dev] Student projects/internships

David Bruant bruant.d at gmail.com
Fri Jan 13 11:35:05 PST 2012

Le 13/01/2012 19:54, Patrick Walton a écrit :
> 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.
I'm not a specialist of the question, but I would guess that it is
I don't see this as a problem, though. Once again, I didn't suggest a
magic tool that will solve all problems. A source-to-source compiler
cannot do a perfect 1-to-1 mapping anyway.
Such a tool would make mistakes. Such a tool would "find" open questions
that it would be preferable a human being answer to. And that's fine. I
wasn't suggesting to do a tool that solves all problems, but rather an
assistant; sorry if the word "compiler" resonated as something that
ambitious, that's not what I meant.

> 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.
It could translate into the unsafe subset (or partially to the safe
subset for parts that are easy to prove if such cases exist) and a human
being could take it from here and get to the safe subset. It sounds much
less work than a human being having to write from scratch in Rust (if
the need is to translate a lot of long programs, of course).

> 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.
Is it true also for the unsafe subset?
If so, then my idea is pointless. If not, then, it probably means you
can "easily" have a compilable unsafe Rust from C/C++ which is a good start.

If a human being brings the unsafe compiled Rust to the safe subset,
then, all the benefits of Rust (static and dynamic ones) will be there
without additional tooling when it comes to maintaining and evolving the
code, since the Rust compiling phase will help during maintenance and
evolution of the code that will be already in Rust.
All these benefits will be harder to achieve in code maintained in C/C++.

> 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.
Is this already in use to analyze Firefox (or equivalent software which
would be as big and in C/C++) in continuous integration?
If not, then it's worth doing the compiler just to have all the benefits
while maintaining/evolving the software.

If the goal is to benefit once from some static/dynamic properties,
then, as you note, additional tools may be easier to set up.
If the goal is to benefit of all the goodness during the software
developement phase (when is Firefox development planned to be finished,
btw? ;-) ), then, it may be worth doing a one-time translation assisted
with a tool that could do 70/80% (guesstimate) of the work.


More information about the Rust-dev mailing list