Rust seems to be the great hope to create a safer programming language. It provides sophisticated checks on what you are doing that make it more difficult to write code that can hide a bug or allow an exploit. The question that new research attempts to answer is - are we writing Rust in a safe way?

The main way that languages enforce safe coding is to place restrictions on what you can do. Sometimes you just cannot live with those restrictions if you want to get the job done, or more often get the job done efficiently. So there is nearly always a "get out clause". In the case of Rust there is the Unsafe keyword which allows you bypass Rust's oversight on what you are doing. For example it allows you to use C-style pointers which are notoriously unsafe and the source of most of the bugs and vulnerabilities we generate.

Even code that is marked unsafe is checked by the compiler and warnings are generated. As well as allowing programmers the freedom to be efficient, or just lazy, the Unsafe  keyword also signals parts of the code that deserve special attention. It says "here be the darkness" that the rest of the language keeps at bay.

The point is unsafe code probably is unsafe and Rust code that is littered with code annotated with Unsafe isn't any better than C code which is probably easier to write.

So how much unsafe code is there and does it have a big effect?

This is the question that Ana Nora Evans, Bradford Campbell and Mary Lou Soffa, a research team from the University of Virginia, set out to answer by looking at Rust libraries.

The short version of the answer is that things aren't as bad as you might imagine, but the impact is complicated. They found that only 29% of Rust libraries include unsafe code. The problem is that dependencies turn that into an effective 50% as libraries that don't use unsafe code import libraries that do. Even worse is that statistic that 60% of the more well-used libraries contain unsafe code. Oddly they also found that Servo project, Mozilla's project to create a Rust rendering engine, had an even higher occurrence of Unsafe.

On the other hand, most of these uses of Unsafe are simply applied to functions that call other unsafe functions and 22% of these eventually call external C libraries - which are by definition as unsafe as you can get.

The better news is that 90% of the libraries had fewer than ten unsafe blocks.

The fact that the most popular libraries use more unsafe code suggests to me that implementing the core things that are needed to get anything done needs unsafe code, if only to make it efficient.

The researchers asked programmers why they used Unsafe and indeed 55% said that it was for reasons of performance. However, 40% said that Rust was too restrictive and 25% said it was too complicated.

We need to look into this more. Is safe Rust really too restrictive and are the 25% just being lazy and not learning Rust well enough.

The researchers suggest that a possible solution is to implement better tools to help programmers:

We propose the following changes to the crates.io interface:

i) a new tag or badge for crates that include Unsafe Rust;

ii) a dependency tree for each library with the crates that use Unsafe Rust clearly marked;

iii) a list of code reviews for any Unsafe Rust.

I also think that the Rust team needs to address the question of why Unsafe is used and find ways of convincing programmers that things can be done without it.

More Information

Is Rust Used Safely by Software Developers?

Ana Nora Evans, Bradford Campbell and Mary Lou Soffa

Related Articles

Rust Survey Revelations

Is Rust Really Safe?

Oxide - A Simpler Formalized Rust

Rust Is A Top Twenty Language

Daily Rust Use Increases, Survey Finds

Rust 2018 Released To Improve Developer Productivity

To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.

Comments

Make a Comment or View Existing Comments Using Disqus

or email your comment to: comments@i-programmer.info