SPLASH 2020
Sun 15 - Sat 21 November 2020 Online Conference
Wed 18 Nov 2020 14:00 - 14:20 at OOPSLA/ECOOP - W-4
Thu 19 Nov 2020 02:00 - 02:20 at OOPSLA/ECOOP - W-4

Rust’s ownership type system enforces a strict discipline on how memory locations are accessed and shared. This discipline allows the compiler to statically prevent memory errors, data races, inadvertent side effects through aliasing, and other errors that occur frequently in conventional imperative programs. However, the restrictions imposed by Rust’s type system make it difficult or impossible to implement certain designs, such as data structures that require aliasing (e.g., doubly-linked lists and shared caches). To work around this limitation, Rust allows code blocks to be declared as unsafe and thereby exempted from certain restrictions of the type system, for instance, to manipulate C-style raw pointers. Ensuring the safety of unsafe code is the responsibility of the programmer. However, a important assumption of the Rust language, which we dub the Rust hypothesis, is that programmers use Rust by following three main principles: use unsafe sparingly, make it easy to review, and hide behind a safe abstraction such that client code can be written in safe Rust.

Understanding how Rust programmers use unsafe code and, in particular, whether the Rust hypothesis holds is essential for Rust developers and testers, language and library designers, as well as tool developers. This paper studies empirically how unsafe code is used in practice by analyzing a large corpus of Rust projects to assess the validity of the Rust hypothesis and to classify the purpose of unsafe code. We identify queries that can be answered by automatically inspecting the program structure, its intermediate representation MIR, as well as type information provided by the Rust compiler, and complement the results by manual code inspection. Our study supports the Rust hypothesis partially: While most unsafe code is simple and well-encapsulated, unsafe features are used extensively, especially for interoperability with other languages.

Wed 18 Nov
Times are displayed in time zone: Central Time (US & Canada) change

13:00 - 14:20: W-4OOPSLA at OOPSLA/ECOOP +12h
13:00 - 13:20
Talk
OOPSLA
Noam YefetTechnion, Uri AlonTechnion, Eran YahavTechnion
Pre-print
13:20 - 13:40
Talk
OOPSLA
Manuel RiggerETH Zurich, Switzerland, Zhendong SuETH Zurich, Switzerland
Pre-print
13:40 - 14:00
Talk
OOPSLA
Yotam FeldmanTel Aviv University, Artem KhyzhaTel Aviv University, Constantin EneaIRIF, University Paris Diderot & CNRS, Adam MorrisonTel Aviv University, Aleksandar NanevskiIMDEA Software Institute, Noam RinetzkyTel Aviv University, Israel, Sharon ShohamTel Aviv university
14:00 - 14:20
Talk
OOPSLA
Vytautas AstrauskasETH Zurich, Switzerland, Christoph MathejaETH Zurich, Switzerland, Federico PoliETH Zurich, Switzerland, Peter MüllerETH Zurich, Alexander J. SummersThe University of British Columbia

Thu 19 Nov
Times are displayed in time zone: Central Time (US & Canada) change

01:00 - 02:20: W-4OOPSLA at OOPSLA/ECOOP
01:00 - 01:20
Talk
OOPSLA
Noam YefetTechnion, Uri AlonTechnion, Eran YahavTechnion
Pre-print
01:20 - 01:40
Talk
OOPSLA
Manuel RiggerETH Zurich, Switzerland, Zhendong SuETH Zurich, Switzerland
Pre-print
01:40 - 02:00
Talk
OOPSLA
Yotam FeldmanTel Aviv University, Artem KhyzhaTel Aviv University, Constantin EneaIRIF, University Paris Diderot & CNRS, Adam MorrisonTel Aviv University, Aleksandar NanevskiIMDEA Software Institute, Noam RinetzkyTel Aviv University, Israel, Sharon ShohamTel Aviv university
02:00 - 02:20
Talk
OOPSLA
Vytautas AstrauskasETH Zurich, Switzerland, Christoph MathejaETH Zurich, Switzerland, Federico PoliETH Zurich, Switzerland, Peter MüllerETH Zurich, Alexander J. SummersThe University of British Columbia