Raw Pointers Research Articles

How Close Is Existing C/C++ Code to a Safe Subset?

Using a safe subset of C++ is a promising direction for increasing the safety of the programming language while maintaining its performance and productivity. In this paper, we examine how close existing C/C++ code is to conforming to a safe subset of C++. We examine the rules presented in existing safe C/C++ standards and safe C/C++ subsets. We analyze the code characteristics of 5.8 million code samples from the Exebench benchmark suite, two C/C++ benchmark suites, and five modern C++ applications using a static analysis tool. We find that raw pointers, unsafe casts, and unsafe library functions are used in both C/C++ code at large and in modern C++ applications. In general, C/C++ code at large does not differ much from modern C++ code, and continued work will be required to transition from existing C/C++ code to a safe subset of C++.

Aliasing Limits on Translating C to Safe Rust

The Rust language was created to provide safe low-level systems programming. There is both industrial and academic interest in the problem of (semi-)automatically translating C code to Rust in order to exploit Rust's safety guarantees. We study the effectiveness and limitations of existing techniques for automatically translating unsafe raw pointers (in Rust programs translated from C) into safe Rust references via ownership and lifetime inference. Our novel evaluation methodology enables our study to extend beyond prior studies, and to discover new information contradicting the conclusions of prior studies. We find that existing translation methods are severely limited by a lack of precision in the Rust compiler's safety checker, causing many safe pointer manipulations to be labeled as potentially unsafe. Leveraging this information, we propose methods for improving translation, based on encoding the results of a more precise analysis in a manner that is understandable to an unmodified Rust compiler. We implement one of our proposed methods, increasing the number of pointers that can be translated to safe Rust references by 75% over the baseline (from 12% to 21% of all pointers).

How do programmers use unsafe rust?

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 frequently occur 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, an important assumption of the Rust language, which we dub the Rust hypothesis , is that programmers use Rust by following three main principles: use unsafe code sparingly, make it easy to review, and hide it 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 analysing 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’s source code, its intermediate representation MIR, as well as type information provided by the Rust compiler; we 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.

Преподаване на C++ като първи език за програмиране

Nowadays, most C++ introductory courses begin by studying the procedural constructs of C language, following the imperative-first strategy described in CC2001 [7]. While this has been a successful approach in the near past, our experience shows that it does not lead to the development of skills to create a good C++ code. That’s why in recent years we’ve been teaching C++ to beginners in a totally different way – with avoidance of C-style strings and raw arrays; delayed introduction to pointers (just after references); polymorphism with references instead of pointers; smart pointers instead of raw pointers; early use of standard library features, and writing modern C++ from day one.

Reconciling high-level optimizations and low-level code in LLVM

LLVM miscompiles certain programs in C, C++, and Rust that use low-level language features such as raw pointers in Rust or conversion between integers and pointers in C or C++. The problem is that it is difficult for the compiler to implement aggressive, high-level memory optimizations while also respecting the guarantees made by the programming languages to low-level programs. A deeper problem is that the memory model for LLVM's intermediate representation (IR) is informal and the semantics of corner cases are not always clear to all compiler developers. We developed a novel memory model for LLVM IR and formalized it. The new model requires a handful of problematic IR-level optimizations to be removed, but it also supports the addition of new optimizations that were not previously legal. We have implemented the new model and shown that it fixes known memory-model-related miscompilations without impacting the quality of generated code.

Comprehensive performance analysis of C++ smart pointers

Smart pointers play an important role in bypassing memory leaks in C++. Since C++11 standard the smart pointers have become widely-used tools because they let the programmers not to deal with memory deallocation. However, abstraction penalty occurs because of this convenience. Overhead is related to runtime, memory usage and compilation time. There are many different smart pointers in the standard library. However, the performance difference between the smart pointers and raw pointers is not measured before. This paper presents an analysis of their effectiveness. An alternative approach to the C++17’s optional construct is searched for.

Implementation of Binary Search Trees Via Smart Pointers

Study of binary trees has prominent place in the training course of DSA (Data Structures and Algorithms). Their implementation in C++ however is traditionally difficult for students. To a large extent these difficulties are due not so much to the complexity of algorithms as to language complexity in terms of memory management by raw pointers – the programmer must consider too many details to ensure a reliable, efficient and secure implementation. Evolution of C++ regarded to automated resource management, as well as experience in implementation of linear lists by means of C++ 11/14 lead to an attempt to implement binary search trees (BST) via smart pointers as well. In the present paper, the authors share experience in this direction. Some conclusions about pedagogical aspects and effectiveness of the new classes, compared to traditional library containers and implementation with built-in pointers, are made.

Implementation of ADS Linked List Via Smart Pointers

Students traditionally have difficulties in implementing abstract data structures (ADS) in C++. To a large extent, these difficulties are due to language complexity in terms of memory management with raw pointers – the programmer must take care of too many details to provide reliable, efficient and secure implementation. Since all these technical details distract students from the essence of the studied algorithms, we decided to use in the course in DSA (Data Structures and Algorithms) an automated resource management, provided by the C++ standard ISO/IEC 14882:2011. In this work we share experience of using smart pointers to implement linked lists and discuss pedagogical aspects and effectiveness of the new classes, compared to the traditional library containers and implementation via built-in pointers.

Using Pit to improve security in low-level programs

Pit (Pedersen on http://pit.devpit.org , 2008; Pedersen and Reza in ISOLA '06: proceedings of the second international symposium on leveraging applications of formal methods, verification and validation (ISOLA 2006), pp. 111---118, 2006) is a new language for low-level programming, designed to be a self-hosting alternative to C. The novelty is that it supports automated memory management without excluding manual memory management, and without hindering key features associated with low-level programming, such as raw pointers, inline assembly code, and precise control over execution. This paper presents Pit as a language, and then examines how Pit's approach to memory allocation can be used to significantly increase the security of low-level programs. Automatic memory allocation is a useful tool of abstraction in many situations. Since Pit provides this tool without hindering low-level programming, it allows automated memory management to be used in programs where it previously could not be used, such as kernels. Specifically, this tool of abstraction can assist the programmer significantly in writing low-level code with fewer security problems caused by buffer overrun or integer overflow bugs by reducing the number of opportunities for such bugs in areas of code that do not need the precision of manual memory allocation. Existing solutions, such as Cyclone (Jim et al. in ATEC '02: proceedings of the general track: USENIX annual technical conference, pp. 275---288, 2002), add various ways of checking bounds, but have two major disadvantages: they require extra work from the programmer, and they detect but do not fix memory allocation bugs. Pit's approach simplifies what the programmer writes, making the code more understandable.

Raw pointers in application classes of C++ considered harmful

In order to achieve good reliability, clarity, scalability and re-usability of the application high-level programs written in C++ the raw pointers should not be used as class members (fields), because the raw pointers are too dangerous in this role and they do not represent meaningful relations between objects. Instead of raw pointers two smart pointers should be used. The first one describes exclusive unique ownership with synchronization of objects copying and deletion. The second one describes inclusive references to independent alien objects with invalidating the reference at the deletion of the addressed object. All power of object-oriented programming is preserved, but difficulties and errors are eliminated.