Table of Contents
Fetching ...

Detecting lifetime errors of std::string_view objects in C++

Reka Kovacs, Gabor Horvath, Zoltan Porkolab

TL;DR

This work tackles lifetime errors stemming from std::string_view usage in C++, where non-owning views can dangle when the referenced string is modified or destroyed. It presents a static analysis tool built as a Clang Static Analyzer checker that models std::string_view operations, maintains string–view associations, and reports use-after-free scenarios with rich bug-path diagnostics. The approach relies on data structures like ViewRegions and CastSymbols, integrates with the InnerPointer module for buffer invalidation, and provides concrete checks for returns, method calls, function arguments, and data access. Initial evaluation shows zero false positives across several open-source projects, and the authors discuss upstreaming plans and future extensions to non-standard string_view variants to broaden practical impact.

Abstract

std::string view is a reference-like data structure in the C++ Standard Template Library (STL) that enables fast and cheap processing of read-only strings. Due to its wide applicability and performance enhancing power, std::string view has been very popular since its introduction in the C++17 standard. However, its careless use can lead to serious memory management bugs. As the lifetime of a std::string view is not tied to the lifetime of the referenced string in any way, it is the user's responsibility to ensure that the view is only used while the viewed string is live and its buffer is not reallocated. This paper describes a static analysis tool that finds programming errors caused by the incorrect use of std::string view. Our work included modeling std::string view operations in the analysis, defining steps to detect lifetime errors, constructing user-friendly diagnostic messages, and performing an evaluation of the checker.

Detecting lifetime errors of std::string_view objects in C++

TL;DR

This work tackles lifetime errors stemming from std::string_view usage in C++, where non-owning views can dangle when the referenced string is modified or destroyed. It presents a static analysis tool built as a Clang Static Analyzer checker that models std::string_view operations, maintains string–view associations, and reports use-after-free scenarios with rich bug-path diagnostics. The approach relies on data structures like ViewRegions and CastSymbols, integrates with the InnerPointer module for buffer invalidation, and provides concrete checks for returns, method calls, function arguments, and data access. Initial evaluation shows zero false positives across several open-source projects, and the authors discuss upstreaming plans and future extensions to non-standard string_view variants to broaden practical impact.

Abstract

std::string view is a reference-like data structure in the C++ Standard Template Library (STL) that enables fast and cheap processing of read-only strings. Due to its wide applicability and performance enhancing power, std::string view has been very popular since its introduction in the C++17 standard. However, its careless use can lead to serious memory management bugs. As the lifetime of a std::string view is not tied to the lifetime of the referenced string in any way, it is the user's responsibility to ensure that the view is only used while the viewed string is live and its buffer is not reallocated. This paper describes a static analysis tool that finds programming errors caused by the incorrect use of std::string view. Our work included modeling std::string view operations in the analysis, defining steps to detect lifetime errors, constructing user-friendly diagnostic messages, and performing an evaluation of the checker.
Paper Structure (26 sections, 2 figures, 1 table)

This paper contains 26 sections, 2 figures, 1 table.

Figures (2)

  • Figure 1: A simplified version of the exploded graph built during the symbolic execution of a simple function. The right-hand side of the graph represents the true branch of the if statement, while the left-hand side describes the false branch.
  • Figure 2: A visual representation of the execution path leading to the bug, augmented with explaining notes, displayed in a browser.