  Rust, an emerging programming language with explosive growth, provides a
robust type system that enables programmers to write memory-safe and data-race
free code. To allow access to a machine's hardware and to support low-level
performance optimizations, a second language, Unsafe Rust, is embedded in Rust.
It contains support for operations that are difficult to statically check, such
as C-style pointers for access to arbitrary memory locations and mutable global
variables. When a program uses these features, the compiler is unable to
statically guarantee the safety properties Rust promotes. In this work, we
perform a large-scale empirical study to explore how software developers are
using Unsafe Rust in real-world Rust libraries and applications. Our results
indicate that software engineers use the keyword unsafe in less than 30% of
Rust libraries, but more than half cannot be entirely statically checked by the
Rust compiler because of Unsafe Rust hidden somewhere in a library's call
chain. We conclude that although the use of the keyword unsafe is limited, the
propagation of unsafeness offers a challenge to the claim of Rust as a
memory-safe language. Furthermore, we recommend changes to the Rust compiler
and to the central Rust repository's interface to help Rust software developers
be aware of when their Rust code is unsafe.
