Is Rust Safe?
Wednesday, 29 May 2024

Rust is our great hope for the future. Even if you are not using it you probably have heard of it and believe it is a safer language than C or C++. But is it really?

Rust is memory-safe because it enforces rules about how you can use memory. In a language like C or C++ you can access more-or-less any memory you want to - simply set a pointer to the required address and access it. Of course, operating systems try to protect against one process accessing the memory of another process, but there are even ways around this.


What this means is that C is a good language if you want to write evil code - but so is Rust. You can access memory in your own way in Rust if you simply add the keyword unsafe to the block of code. However, if you don't do this then Rust will attempt to keep track of your memory usage and will try and stop you from making mistakes. I suppose you could say that C and unsafe Rust are both unsafe but...

Rust at least tries to protect you and to actually step outside this protection you have to explicitly use the unsafe keyword. A Rust program that doesn't use unsafe has to comply with the rules of ownership, otherwise it doesn't compile. The only way you can write an unsafe Rust program is to mark the offending sections of code as unsafe and this is claimed to be enough to keep you safe as you have to at least think about what you are doing. The unsafe keyword enables developers to dereference a raw pointer, modify a mutable static variable, and, crucially, call unsafe functions - basically things you can do in C without thinking too hard or at all really.

A recent blog post at the Rust Foundation makes the claim that unsafe code is still safer than C code:

  1. unsafe has to be isolated in its own code blocks. If anything goes wrong while using Unsafe Rust, it is clear what code has likely caused the issue.
  2. There are a limited number of ways to use unsafe  and all safe Rust code continues to have its normal safety checks even inside an unsafe block.
  3. The Rust type system still provides safety constraints for safe Rust types even within an unsafe block.

To find out how common unsafe code was the Rust Foundation also surveyed 127,000 crates, i.e. Rust libraries, and found that unsafe was used in around 19% of them and 34% made a call to a crate that used unsafe. The most unsafe crate was the Windows crate which clearly had to make calls into the unsafe Windows API.

However, what isn't made clear, is that the ownership model that makes Rust memory safe only works with data structures that are essentially trees - i.e. no circular references - and this makes unsafe unavoidable for some types of program.

What other limiting factors are there that cause programmers to have to use unsafe? The survey doesn't address this question and it is an important one. We tend to think that programmers use unsafe when they are being lazy and can't be bothered to extend safe memory management to their code. Either that or some really unavoidable need to use external unsafe code is the problem. Are there cases where unsafe is being used because, even in an ideal world, there is no alternative - as in trying to build a doubly-linked list.

While it is clear that Rust is a safer language, if only because it focuses the mind on unsafe code, this is not enough. We need some hard facts on what drives a good programmer to be unsafe.


  •  Mike James is Chief Editor of I Programmer and the author of several programming books in the I Programmer Library. Safe and unsafe behavior is one of the topics in his soon-to-be-published "Deep C Dives".  

More Information

Unsafe Rust in the Wild: Notes on the Current State of Unsafe Rust

Related Articles

Rust Twice As Productive As C++

Google Says You Got Rust Wrong - It's Great!

Rust Fast And Safe

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.



OpenSSF's Siren To Warn About OSS Vulnerabilities

Siren is a new mailing list by the OpenSSF which aims to monitor the threat landscape of open-source project vulnerabilities in order to provide real time alerts to anyone subscribed.

Deno Adds Support For Private npm Registries

Deno 1.44 has been released with support for private npm registries and for gRPC connections.

More News

C book



or email your comment to:

Last Updated ( Wednesday, 29 May 2024 )