# How Close Is Existing C/C++ Code to a Safe Subset?
## 1 Introduction  
For decades, the lack of memory safety in C and C++ has been the culprit behind a significant number of software vulnerabilities [1]. C allows for unchecked access to memory through pointers and arrays, and C++, its predecessor, maintains the same capabilities. These features make C and C++ powerful languages, giving programmers direct control over memory layout, allocation, and access. However, programmers often make mistakes involving memory, and these mistakes can lead to security vulnerabilities. Despite the numerous available approaches for preventing memory safety errors in these languages, developers have been hesitant to adopt any of them. Following the rise in popularity of languages like Rust, multiple organizations have advised that software developers should transition away from using languages like C and C++ in favor of memory-safe languages [2; 3]. In response, the C++ Standards Committee released a report on the future direction for ISO C++ [4]. As part of their response, the committee indicated that moving toward defining a _safe subset_ of C++ could serve the purpose of allowing applications to be written in C++, thus gaining the advantages of C++'s performance and productivity while improving the safety of code written in C++. A safe subset of C/C++ restricts or bans the use of unsafe language features and, when necessary for productivity or performance, replaces unsafe language features with safer variants that accomplish the same goal. Prior work [5; 6; 7; 8] has aimed to design a safe subset of C/C++. These efforts have generally restricted the use of types and operations that may allow unsafe accesses to memory when used incorrectly, and they have statically restricted the use of features outside of the safe subset via a compiler or static analyzer. Our goal is to understand how close existing code is to conforming to a safe subset and to highlight the work that would be required to transition from existing C/C++ code to a safe subset of C++. We examine code that is predominantly C, predominantly C++, and a mix of both to investigate how the work required to conform to a safe subset might vary between code bases. To accomplish this task, we applied a static analysis tool that identifies potentially problematic code constructs in existing C/C++ code. We ran this static analysis tool on 5.8 million code samples from the Exebench benchmark suite [9], two C/C++ benchmark suites (LLVMTest and SPEC 2017) [10; 11], and five modern C++ applications [12; 13; 14; 15; 16]. We analyzed the data to determine (Q1) how often raw pointers, voidpointers, and smart pointers are used in existing C/C++ code, (Q2) how commonly unsafe constructs are used in existing C/C++ code, and (Q3) how much \"modern\" C++ code differs, in terms of using unsafe constructs, from C/C++ code at large. This paper makes three main contributions. * We summarize the existing work on safe C/C++ standards and the safe subsets of C/C++. * We present a static analysis tool and methodology for identifying potentially problematic code constructs in the existing C/C++ code. * We analyze the data from 5.8 million code samples in the Exebench benchmark suite, two C/C++ benchmark suites, and five modern C++ applications to determine how close existing C/C++ code is to conforming to a safe subset of C++. The remainder of the paper is organized as follows. Section 2 provides background information on the recent arguments over the safety of C/C++ and the motivation to transition toward a safe subset of C++. Section 3 analyzes and compares a set of existing safe C/C++ standards. Section 4 discusses the prior work on safe subsets of C/C++. Section 5 introduces our experimental methodology and provides background information on the Exebench benchmark suite, the LLVMTest and SPEC 2017 benchmark suites, and the modern C++ applications studied in the remainder of the paper. Section 6 presents the results of our experiments and discussion on the state of existing C/C++ code in relation to a safe subset of C++.