DEV Community: Unicorn Developer

Why do we integrate PVS-Studio analyzer with so many tools?

Unicorn Developer — Tue, 08 Sep 2026 14:22:42 +0000

PVS-Studio analyzer already provides dozens of integrations with various tools and services, and in this article, we'd like to explain why.

We develop and sell PVS-Studio static analyzer with a wide variety of features such as command-line utilities, diagnostic rules in various categories, support utilities, and so on.

Behind "so on", we usually mean numerous integrations with third-party tools (plugins, extensions, and usage scenarios). But why do we hide them? You can see that by yourself: the first PVS-Studio integration was a plugin for Visual Studio 2005, released 18 years ago. Today, the analyzer integrates with more than three dozen other development tools: IDE plugins, game engines, code quality platforms, build systems, CI/CD platforms, and more.

Keeping all these integrations up to date and working properly takes a lot of effort, and now we'll explain why we do it in the first place.

Convenience of use

The most daunting thing when you think about integrating a new tool is the complexity of the implementation process. What's more, this feeling arises among both managers and engineer—don't forget about the principle of "If it works, don't touch it".

And it's okay because every company or team has its own approaches and tools, and when it comes to implementing something new, it seems complicated. And often it's not just about inner feelings—the implementation process is often quite complex.

Actually, that's the main reason we're working to develop integrations for popular tools. If you're already using a specific set of IDEs or a particular web dashboard for DevSecOps, why force you to use something we've come up with? Instead, we suggest expanding the familiar set of features to include the ability to use our tool.

Also, different people on the team may need different tools: developers search for the easy run of the static analyzer during development, and manager would like to quickly view warnings' statistics in a web dashboard. That's why we're creating so many integrations.

Usage scenarios

Yes, the static analyzer doesn't usually seem like a hard-to-use tool, but its initial configuration varies greatly depending on the project and the required use cases.

Let's take a look at some use cases using specific examples.

On-premise analysis

The static analyzer runs on developers' machines so they can check their code before the commit to the version control system.

It may seem that a fairly straightforward and user-friendly CLI would be enough—we're engineers, after all. But in reality, "to each his own". Some people prefer a specific IDE, while others would sell their souls for Vim.

We need to know how to work with all of this, that' why PVS-Studio offers plugins for all the most popular IDEs used for development in the languages supported by our analyzers:

It might seem like all this isn't worth the effort, but IDE plugins can significantly reduce the time it takes to go from an idea to a result: open a project, click a button, and get the analysis results in just a few seconds or minutes.

As a result, we move all the tedious but important part of integration from the user to our tool: we ask the build system what language, type, and specifics of the project is here, then obtain a list of files for analysis, apply the main settings; display the progress and results; and provide user-friendly access to auxiliary tools.

For example, one way to suppress false positives is to use special comments in the code. If you're working from the terminal, you have to build the whole new process:

find the warning position in the report file;
go to that line in the file;
add a comment with the diagnostic rule number;
~~try to remember how to exit from Vim~~.

It's not exactly difficult. The IDE plugins streamline this path to just a couple of clicks, without having to read the documentation or switch between tools.

If the IDE integration isn't an option, integrations with build systems can help. For example, you can configure the analysis of Java projects using integrations with Gradle and Maven, and for CMake, there are actually two integrations: one using our CMake module and one using the utility's own built-in mechanisms (official Kitware integration was added in version 4.3.0).

We wrote about the official integration into CMake in a separate article.

Continuous integration

The next major step in using static analysis is to integrate it into CI for automatic analysis updates. This stage involves a wide range of implementation options, which is why the list of integrations here is quite diverse.

For example, among on-premises solutions, there are integrations with Jenkins and TeamCity; among cloud-based solutions, there are GitHub Actions and GitLab CI/CD.

For automation, it may also be helpful if the tool can run in containerization and virtualization environments, such as Docker and WSL.

By the way, automatically running static analysis is important not only in CI but also for regular analysis.

Regular analysis

The regular analysis periodically runs an analysis of the entire project during nightly builds that helps determine whether there are any errors in the project as a whole, because during local analysis and in CI, we usually check only individual updates.

This stage, in addition to the mentioned integrations, requires web dashboards and code quality monitoring systems: the entire project is analyzed on the server, and we need to ensure that the whole team can collaborate on the resulting report.

Plus, this collaborative work involves both reviewing the report and marking up warnings. Managers, meanwhile, can use various metrics to track the results and distribute the work among team members.

A code quality monitoring platform serves as a centralized repository of information on how code quality has changed over time within a project, which is why this tool is of practical use to managers.

Among its web dashboards, PVS-Studio supports integrations with SonarQube, DefectDojo, and CodeChecker.

Specific usage scenarios

We don't forget about development specializations. Why does it matter? The reason is the same as before, we just integrate into other tools that are specific for a certain dev area.

The first specialization that PVS-Studio supports is game development. For game dev projects, we support integrations with Unreal Engine and Unity.

Our tool can be also involved into development of embedded systems. Due to the nature of embedded systems, there's a huge variety of compilers, and they can differ significantly from one another. That's why we strive to make sure the analyzer works with the compilers and SDKs our customers use, including IAR Embedded Workbench, QNX Momentics, Keil µVision, Texas Instruments Code Composer Studio, and others. You can always find the complete list on the website.

Conclusion

We hope we've managed to explain that integrations for PVS-Studio aren't just a checkbox in a checklist—it makes static analysis a convenient and seamless part of the user's workflow.

We use these tools to make static analysis a convenient and seamless part of the workflow.

From our very first Visual Studio 2005 plugin to the present day, we've been working to make PVS-Studio go where our users work.

If you haven't tried testing your project with our analyzer yet, you can start on this page.

And if you're already using PVS-Studio and have something to say about it, you can write to us using this form. For example, we'd be interested to know what integrations you feel are missing from the product.

Clean code to you, folks!

The worst programming language of all time /s

Unicorn Developer — Fri, 04 Sep 2026 14:17:09 +0000

In this article, the author looks at why C++ feels so complicated, and why its flaws are inseparable from its long-term success.

We published and translated this article with the copyright holder’s permission. The author is Sergey Kushnirenko

There's a video on YouTube—a little over fifty minutes long, with a rather bold title: "The worst programming language of all time." I wouldn't be surprised if you assumed it was about C++. You'd be right. I first watched it about six months ago—or rather, skimmed it at 2x speed with plenty of skipping. I figured it was just another rant from a frustrated junior developer. Recently, though, a fellow community member brought it up again, so this time I watched the whole thing. And you know what the worst part is? If you focus purely on the substance and set aside the tone of an offended junior dev, about 70% of the arguments turn out to be valid. Not debatable, not "it depends on the context." Just plain facts that almost any developer who's spent a couple of years with C++ would confirm without hesitation.

The paradox is that the video takes aim at the language behind half the software around us. That includes the browser you're reading this in, the engine that powered the game you played yesterday, the firmware running on the hardware underneath, and even the compiler that built all of it.

The "C++ is terrible" narrative has been a cliché forever. You've probably read dozens of articles about the initialization-order fiasco, the overloaded static, the poorly named vector, the fact that std::move doesn't actually move anything, the painfully slow regex, and the underwhelming performance of unordered_map. None of these complaints are new. What I'd like to point out is that every issue and example I cover below stems from the same fundamental design decision. If you can't wait, open the spoilers—they explain the history behind each part of the language and why it turned out the way it did.

There's more than one way to initialize a variable

Let's start with the deepest circle of hell—the beginning of every program: creating a variable. In most languages, that's a single, straightforward operation. In C++, however, people write entire books about it. They publish research papers, give conference talks, and dissect every corner case as if the language didn't have enough other problems already. Did I miss anything? Please let me know.

int f;                    // automatic storage, garbage
static int f_static;      // but the namespace/static scope already has zero 
                          // (zero-init in the beginning)

std::string s;            // a call to the default constructor
int* p = new int;         // a heap, garbage
int e{};                  // 0
int e2 = {};              // 0
int* p = new int{};       // 0
int* q = new int();       // it's 0 too
auto t = T{};             // temporary, value-init
int b(5);
std::string s("hello");
T obj(a1, a2);
auto p = new T(a1, a2);
int x = static_cast<int>(3.5);   // a cast, it's also a direct-init
int y(int(5));                   // functional notation
int a = 5;
std::string s = "hello";
T obj = other;
f(arg);                   // pass by value; the function's 
                          // PARAMETER is initialized

                          // an invisible variable
f({1, 2, 3});             // same
return x;                 // return by value
return {1, 2, 3};         // same, if copy-elision doesn't work
throw x;                  // an exception object is initialized
int c{5};                 // direct-list
int d = {5};              // copy-list
std::vector<int> v{1, 2, 3};
std::vector<int> v2 = {1, 2, 3};
std::vector<int> a(10);   // 10 elements, all zeros
std::vector<int> b{10};   // ONE element has a value of 10
struct Point { int x, y; };
Point p{1, 2};            // you can do it this way
Point p2 = {1, 2};        // or you can do it that way
int arr[3] = {1, 2, 3};   // with or without zeros
int arr2[3] = {};         // all zeros
Point p3{.x = 1, .y = 2}; // designated initializers, C++20
Point p4{1};              // x=1, y=0 (value-init tail)
int& r = x;
const int& cr = 5;        // linked to temporary + extending lifetime
int&& rr = 10;
constexpr int n = 42;     // it must be constant-init
const int m = foo();      // it can be either constant or dynamic
constinit int g = bar();  // C++20: guarantees static-init, 
                          // but DOESN'T make it const
static int s = compute(); // dynamic-init, with its Static Init Order Fiasco
struct S {
    int x = 5;            // default member initializer
    int y{10};
    S() : y{2}, x(1) {}   // member initializer list 
                          // (in the order of declaration, not by list)
};
auto [a, b] = std::pair{1, 2};   // structured bindings, C++17
for (int v : arr) { }            // range-based for initializes v too

If we count the distinct initialization semantics, we end up with around ten different forms (= v, (v), {v}, = {v}, {}, = {}, () in new, and so on). These map to nine different semantic categories, and the relationship between syntax and semantics is far from one-to-one. Depending on the right type, the same {} syntax can mean value-init, list-init, or aggregate-init. There's even a dedicated 300-page book on C++ initialization—and no, this isn't a joke. A friend once recommended it to me. It really exists, and it really is 300 pages long. Enjoy.

Every initialization form behaves just a little differently. My favorite is the difference between e and f, where the presence or absence of a pair of braces determines whether your variable holds zero or whatever bits the previous function call left on the stack.

struct S {
    int x = 5;     // default member initializer
    int y{10};
};

NSDMI stands for Non-Static Data Member Initializer—an initializer for a non-static data member written directly in the class definition. When we write int x = 5;, no object exists yet, so nothing is initialized. What we have instead is a default member initializer, a fallback the compiler uses during object construction ONLY IF the constructor doesn't initialize that member in its mem-init-list. In other words, it's a recipe for default initialization, not an actual initialization. Technically, it's a brace-or-equal-initializer for a member.

auto [a, b] = std::pair{1, 2};

Here the compiler initializes a hidden unnamed object (commonly called the hidden object or the decomposition object—let's call it e). The names a and b aren't independent variables; they're bindings to parts of that unnamed object. The initialization applies to e, not to a or b. It's a subtle distinction, but since we're being precise, it's worth pointing out again that they aren't real variables so much as structure members, and that e isn't directly accessible. The storage, however, looks roughly like this:

e
+---------+
| first   | <--- a
| second  | <--- b
+---------+
auto e = std::pair{1, 2};
auto& a = e.first;
auto& b = e.second;

Asm

int k, e;

int main() {
    auto [a, b] = std::pair{k, e};

    return a + b;
}
----------------------------------------

leaq    -12(%rbp), %rdi
leaq    k(%rip), %rsi
leaq    e(%rip), %rdx
callq   std::pair<int, int>::pair<int&, int&, true>(int&, int&)

This is where a hidden structured binding object is created. The rdi argument is the first argument to the constructor—that is, the address of where pair is constructed.

main:
        pushq   %rbp
        movq    %rsp, %rbp
        subq    $32, %rsp
        movl    $0, -4(%rbp)
        leaq    -12(%rbp), %rdi  <<<<<
        leaq    k(%rip), %rsi    <<<<<
        leaq    e(%rip), %rdx    <<<<<
        callq   std::pair<int, int>::pair<int&, int&, true>(int&, int&) <<<<<
        leaq    -12(%rbp), %rdi
        callq   tuple_element<0ul, std::pair<int, int>>::type && 
                              std::get<0ul, int, int>(std::pair<int, int>&&)
        movq    %rax, -24(%rbp)
        leaq    -12(%rbp), %rdi
        callq   tuple_element<1ul, std::pair<int, int>>::type && 
                              std::get<1ul, int, int>(std::pair<int, int>&&)
        movq    %rax, -32(%rbp)
        movq    -24(%rbp), %rax
        movl    (%rax), %eax
        movq    -32(%rbp), %rcx
        addl    (%rcx), %eax
        addq    $32, %rsp
        popq    %rbp
        retq

k:
        .long   0

e:
        .long   0

And just when we think we've got it, we find out that braces can mean aggregate initialization in one context and std::initializer_list in another, and that the same line of code may yield a different type depending on which version of the standard you compile against. Not a different result—a different type. Welcome to C++.

auto i = 1;      // always int
auto j = {1};    // initializer_list<int> is always (copy-list-init)
auto k{1};       // C++11: initializer_list<int>;  C++17+: int

The origin of the zoo

The initialization zoo grew out of an attempt to eliminate... the initialization zoo! In 2011, the committee genuinely tried to unify everything under a single syntax. Instead, it added one more enclosure to the zoo.

From C, C++ inherited initialization for declarations (int a = 5;) and braces for aggregates such as arrays and structs (int arr[] = {1,2,3};). In C, braces simply distributed values across the members of a POD aggregate. They were never meant to do anything else.

Then C++ introduced constructors. Once they existed, they needed a way to run when an object was created. Parentheses felt like the most natural choice, since a constructor call looks a lot like a function call—hence Widget w(args);. Makes sense? Absolutely.

Right up until the day you write Widget w(); and realize you've declared a function returning Widget. That's the infamous most vexing parse. It isn't an implementation bug but a direct consequence of the grammar inherited from C, where declarations are designed to resemble usage. That design also makes a function declaration syntactically indistinguishable from constructing an object with empty parentheses.

Then came C++11 and its great invention: uniform initialization. The goal was admirable—introduce a single syntax, {}, that works everywhere, whether you're initializing aggregates, classes with constructors, scalars, or containers.

As a bonus, it would eliminate the most vexing parse, because Widget w{}; can never be parsed as a function. It would also reject narrowing conversions: int x{3.5}; is a compilation error, whereas int x = 3.5; silently truncates the fractional part.

In other words, {} wasn't meant to become yet another initialization syntax. It was supposed to be the initialization syntax—the one true way that would eventually replace all the others.

This is where we run into the issue that explains so much about C++. To make {} the only syntax, the language would have had to drop = and (). But those appear in billions of lines of code—engines, libraries, and third-party APIs all rely on them.

So the old syntax couldn't be removed, and the new universal syntax didn't replace the older ones; it simply found a niche of its own, and now we have even more options. The feature meant to shut down the zoo became its most famous exhibit.

To make things even more entertaining, braces later picked up a second meaning through std::initializer_list. If a type has a constructor taking an initializer list, braces select it, and it takes precedence in overload resolution.

The difference between int e{}; (zero) and int f; (garbage) is a separate story. That behavior comes from C, where automatic variables were never zeroed by default. This wasn't an oversight but a deliberate design choice: zero-initialization costs CPU cycles, and C's philosophy has always been "you don't pay for what you don't use." If you wanted zero, you were expected to write it yourself.

That's why int f; leaves behind bits from the previous function call's stack frame. It's by design—a feature dating back to C, around 1972. Later, Stroustrup wanted to offer a safe, zero-initialized default, but he couldn't make it the language default without breaking both backward compatibility and C's core philosophy of "don't pay for what you don't use." So the safe option exists, but it isn't the default, because the default was fixed half a century ago in the name of performance.

At this point, unifying everything under a single initialization syntax is impossible. Every form has accumulated its own code, semantics, and rules. So when yet another 300-page book on C++ initialization appears—or someone presents a flowchart that takes up half the screen—that isn't the authors showing off. It's the price of everything that's been put into the language over the past forty years, all because of its most defining feature.

Simple things are the hardest to do

A textbook example of needlessly complicated simplicity is generating a random number. In Java or Python, you'd just write something like random.randint(1, 100) and get on with your code. Not in C++, though. That would be far too simple.

std::random_device rd;
std::mt19937 gen(rd());                          // what's mt19937?
std::uniform_int_distribution<int> dist(1, 100); // why is it separated?
int value = dist(gen);                           // finally

The code is readable enough, but I still found myself checking CppReference every other time I needed to. Then I had to Google what mt19937 actually is. Turns out it's the Mersenne Twister. Congratulations—you now know the name of a pseudorandom number generator. Apparently, that's knowledge you're expected to have just to roll a die in C++.

Simple things

Before C++11, the language relied on rand(), inherited from C. It returns a number in a range bounded by RAND_MAX—a value the standard guarantees to be at least 32,767. On some platforms, that makes it impossible to get a uniformly distributed number across a wide range.

The familiar rand() % 100 introduces modulo bias, because 100 doesn't evenly divide the number of possible outputs. Some values come up more often than others, and the resulting sequence isn't even reproducible across compilers. In other words, rand() was a wonderfully simple way to shoot yourself in the foot.

That's why C++11 adopted an entirely new design borrowed from Boost.Random—one that deliberately pulled apart everything rand() had lumped together. Now there's the engine itself, the source of raw random bits (mt19937, a.k.a. the Mersenne Twister, designed by Matsumoto and Nishimura in 1997). Then there's a distribution that turns those raw bits into uniformly distributed values over a given range without introducing bias. And finally there's a separate seed source.

This design came from people who needed reproducible Monte Carlo simulations for scientific computing, and for that use case it worked brilliantly. The problem is that they built a magnificent cathedral and never bothered to add a small side door for "roll a number between 1 and 100." To this day, the C++ standard library offers no one-line randint().

Even the "correct" incantation isn't actually correct, though. First, mt19937 carries nearly 20,000 bits of internal state, yet we usually seed it with a single 32-bit value from std::random_device. In other words, we're severely undersowing the generator.

Then there's std::random_device itself. The standard explicitly permits implementations to make it deterministic, and for years older MinGW versions returned the same sequence on every program start. So the long, supposedly correct spell is indeed long, and technically correct but it still doesn't work reliably everywhere. Meanwhile, rand() % 100 is shorter and actually works.

Casting problems

Casting is a whole different story. In Java, we just put the target type in parentheses and move on. In C++, we get an entire collection of casts, each built for a specific purpose: static_cast, dynamic_cast, reinterpret_cast, const_cast, bit_cast—every one with a full name you have to spell out each time. There's also the hidden rvalue_cast, but we'll get to that in a moment.

double d = 3.9;
int i = static_cast<int>(d);        // 3, the decimal part is omitted

Base* b = new Derived;
auto* der = static_cast<Derived*>(b); // downcast WITHOUT checking 
                                      // you guarantee that it's Derived

Base* b = get_something();
if (Derived* d = dynamic_cast<Derived*>(b)) {
    d->derived_only();              // you can get here only if it's Derived
}                                   // otherwise d == nullptr

// an address as a number
int x = 42;
std::uintptr_t addr = reinterpret_cast<std::uintptr_t>(&x);

void legacy_api(char* s);    // It didn't modify the line but missed const

const std::string str = "hello";
legacy_api(const_cast<char*>(str.c_str()));  // it's OK, 
                                             // since the API isn't modified

float f = 1.0f;
auto bits = std::bit_cast<std::uint32_t>(f);  // 0x3F800000, no UB

// how they did it before C++20:
std::uint32_t old;
std::memcpy(&old, &f, sizeof f);              // the same thing but manually

int i = (int)d;                     // it compiles and looks familiar

Beginners often find this so frustrating that they end up creating a short alias. This is considered poor practice because the code is written in a personal C++ dialect that only the creator understands.

// the "I'm tired of writing static_cast" anti-pattern
template <class T, class U>
constexpr T sc(U&& u) { return static_cast<T>(std::forward<U>(u)); }

int i = sc<int>(3.9);               // is it short? yep. 
                                    // is it correct? nope.

// it may be even worse:
#define CAST(T, x) static_cast<T>(x)

This is where the language really starts to mess with you. Correct C++ often looks incorrect, because the short, elegant solution is usually buggy or subtly flawed, while the correct one looks like the author went out of their way to make life harder for everyone on the team. Developing an intuition for what good C++ code looks like takes years. Until then, it feels like you're constantly doing something wrong. Spoiler: you probably are—that's just how the language works.

Why so chonky?

C has the (T)expr C-style cast, and it does everything. It can change values, reinterpret pointers, strip const, narrow types, and more—all with exactly the same syntax. The result is that nowhere in a codebase can you tell where someone cast away const, because those casts look identical to any other conversion.

C++ split this "Swiss Army knife" into four named operations—static_cast, dynamic_cast, const_cast, and reinterpret_cast—precisely because in C they were indistinguishable.

The point was to make the intent explicit and to ensure that const_cast, which undermines const, would catch a reviewer's eye. The idea was to make casts easy to grep, so a programmer could find and inspect every reinterpret_cast in a codebase.

Casts are treated as a necessary evil, so the language designers deliberately made them ugly. As Andrei Alexandrescu famously put it, a cast is a code smell. Stroustrup intentionally chose a verbose syntax so that explicit casts would be painful to type and would stand out immediately in code review. The old C-style cast was too lightweight, and that's exactly what made it so dangerous.

That's why the correct solution in C++ so often looks wrong—not by accident, but by design. The short, elegant version is usually broken legacy that can't be removed because of the language's most important feature: backward compatibility. The correct one is deliberately wordy and awkward. Its purpose is to make you stop and think about every explicit conversion you write.

Keywords that lie

In a sane world, a keyword describes what it does. In C++, that's more of an optional feature. Take static, for example.

How many meanings does it have again? First, it creates a variable that survives between function calls. Second, it makes a variable or member function belong to all instances of a class. Third, placing static before a function in a .cpp file makes that function invisible from the outside, so it behaves like private but is named static. Why not internal, private, or file_local? Well, that's just how things are, which answers about half of the questions in this article.

void counter() {
    static int calls = 0;   // it's initialized ONCE, on the first entry
    int local = 0;          // a normal local; each call is made anew
    ++calls;
    ++local;
    std::cout << "static: " << calls << ", local: " << local << '\n';
}

The static keyword, which was introduced after C++11, now implies that static also means light mutex-guarded. Did you know that?

Logger& logger() {
  static Logger instance;   // a one line
  return instance;
}

Logger& logger() {
  // the QUICK way: if the least significant byte of guard != 0, 
  // it's already been initialized
  if ((reinterpret_cast<volatile char&>(__guard_for_instance)) == 0) {

    // the SLOW way: we only go this way the first time, 
    // and only when we're in sync
    if (__cxa_guard_acquire(&__guard_for_instance)) {
      // `acquire` returned 1, 
      // so this thread is responsible for initializing it
      // the other threads are currently SLEEPING inside __cxa_guard_acquire
      try {
        ::new(&__instance_storage) Logger(); //the call to the constructor
         __cxa_guard_release(&__guard_for_instance);  // we set the flag
                                                      // and wake the sleepers
         __cxa_atexit(&destroy_logger, ...); // we register the destruction
      } catch (...) {
        __cxa_guard_abort(&__guard_for_instance);      
        throw;
      }
    }
    // the threads that lost the race left the acquire block after release
  }
  return reinterpret_cast<Logger&>(__instance_storage);
}

Why static does four unrelated things

In C, static already had two distinct meanings. The first and more familiar one controls storage duration—the variable exists for the entire lifetime of the program.

The second controls internal linkage, meaning the name isn't visible outside the translation unit. Semantically, these two ideas have almost nothing in common: one is about object lifetime, the other about symbol visibility. Yet K&R folded them into a single keyword. Their reasoning was simple: C should have as few keywords as possible, and static was close enough to "statically allocated."

C++ inherited both meanings unchanged. Dropping either one would have meant breaking compatibility with C—exactly the outcome the language was trying to avoid. Later, when Stroustrup introduced class members shared by all instances, he could have added a new keyword such as shared or classwide, or something descriptive in the spirit of private and protected. But by then it was already clear that every new keyword added to the language was a potential landmine for developers.

By that point, someone somewhere had almost certainly named a variable shared, internal, or classwide. The moment one of those words became a keyword, their code would stop compiling. That's why the language designers tried to reuse existing keywords wherever possible instead of inventing new ones. And since static was already in the language, its meaning was already somewhat overloaded—one more interpretation didn't risk breaking anyone's production code. So static picked up a third meaning, not because it was the best semantic fit, but because the keyword was already there, and reusing it preserved backward compatibility.

A fourth behavior arrived with C++11, when initialization of function-local static variables was made thread-safe. To pull that off, compilers began emitting a hidden guard that ensures initialization happens exactly once.

There was one attempt to clean things up. In C++98, using file-scope static for internal linkage was officially discouraged in favor of unnamed namespaces. But C++11 walked that recommendation back, because breaking developers' long-standing habits proved more costly than changing the language. In other words, C++ couldn't get rid of a meaning it had already declared obsolete.

Realistically, none of the four meanings can be removed now. Each has code depending on it—a local counter, a private helper function, or a class member that's part of a public API used by hundreds of thousands of developers.

The inline keyword once prompted the compiler to inline a function. Today, compilers are smart enough to decide on their own, and inline has mostly become a tool for dealing with linkage and the One Definition Rule. To make things stranger, inline means almost the opposite depending on what you apply it to: for a function, it allows code duplication, while for a variable, it prohibits data duplication.

// math.h
inline int square(int x) { return x * x; }

// a.cpp
#include "math.h"
int use_a() { return square(3); }

// b.cpp
#include "math.h"
int use_b() { return square(4); }

// counter.h
inline int g_calls = 0;   // there's only one instance for the entire program

// a.cpp
#include "counter.h"
void hit_a() { ++g_calls; }

// b.cpp
#include "counter.h"
void hit_b() { ++g_calls; }

// config.h
struct Config {
  static inline int instances = 0;  // there's one counter for all objects in .h
};

inline constexpr double kPi = 3.14159265358979; // its a header-only constant, 
                                                // a single object

What inline was designed for

In early C++, inline was a type-safe replacement for a #define macro. The idea was simple: instead of a function call, substitute the function body directly at the call site. It was literally an optimization based on inline expansion. That's where the name comes from, and that's why many developers still believe inline means "make this faster." That hasn't been true for at least the past fifteen years.

Today its primary purpose has little to do with optimization. Instead, inline is about the ODR and linkage. An inline entity may have definitions in multiple translation units—for example, when you put the definition in a header and include it everywhere. The linker then has to merge those definitions into a single entity rather than failing with a multiple definition error.

So what does inline have to do with actual inlining these days? Very little. As an optimization hint, it's purely advisory. Modern compilers routinely ignore it because they rely on sophisticated cost models. They'll happily inline functions that aren't marked inline and refuse to inline ones that are. With LTO enabled, they can even inline across translation-unit boundaries whether the keyword is there or not.

These days inline is only indirectly related to real inlining. Its actual job is to let you put a definition in a header without triggering linker errors—and the optimizer can keep the visible body in a separate TU, since LTO is impossible without it.

Member functions defined directly in a class body are implicitly inline. So are all constexpr functions. Yet developers still write the keyword just in case, even though it changes nothing.

Now we force inlining with __forceinline (MSVC) and __attribute__((always_inline)) or [[gnu::always_inline]]—and even those often fail in the presence of recursion, varargs, or taking a function's address. The name is a relic of a time when it really did work that way; now it's a message to the linker.

The const keyword is supposed to mean immutability, yet you can write it on either side of a type, and both forms mean exactly the same thing—just to keep you on your toes. It gets better: mutable const is sometimes valid code. You can also manually remove the constness. It's not ideal but technically possible.

The official advice for determining whether const in a pointer declaration applies to the pointer or to its value is to read it from right to left, but most people read from left to right.

const int a = 5;   // "west const"
int const b = 5;   // "east const" is exactly the same; both are constants

const int* p = &a; // the pointer to const int
int const* q = &a; // this is the same thing

struct Cache {
    mutable int hits = 0;   // can be changed even for a const object
    int value = 0;
};

const Cache c;
c.hits++;       // OK, mutable
// c.value++;   // this is an error; a regular member of a const object

struct S {
    mutable const int* p = nullptr;  // VALID
};

struct Bad {
    mutable const int x = 5;  // INVALID: mutable can't be used 
                              // on a const member
};

// Case 1: The object is ACTUALLY not const, OK
int x = 5;
const int& cref = x;
const_cast<int&>(cref) = 10;   // correct: x indeed changed, x == 10

// Case 2: the object is ACTUALLY const, Undefined Behavior
const int y = 5;
const_cast<int&>(y) = 10;      // it compiles, but it's UB
                               // y could stay at 5, drop, or anything else

int x = 0, y = 0;

const int* p1 = &x;        // p1: pointer to const int
int* const p2 = &x;        // p2: const pointer to int
const int* const p3 = &x;  // p3: const pointer to const int

*p1 = 5;   // error: const value
p1 = &y;   // OK: the pointer can be redirected

*p2 = 5;   // OK: the value can be changed
p2 = &y;   // error: const pointer

*p3 = 5;   // error
p3 = &y;   // error

Why use const if memory isn't const?

The const keyword originated in C++ and was later adopted by C, not the other way around. Stroustrup introduced it back in "C with Classes"—initially under the working name readonly. From there it made its way into the C89 standard and took on a life of its own. Ironically, the keyword created to bring order immediately inherited the quirks of the grammar it was dropped into.

First, const int and int const are literally the same thing: const is a type qualifier living in the decl-specifier-seq, the sequence of declaration specifiers.

That sequence was unordered long before const came along, for the same reason unsigned long and long unsigned name the same type. So const inherited an old quirk: the order of specifiers already didn't matter. The more consistent form is actually int const, because const conceptually applies to whatever sits immediately to its left. The alternative, const int, exists largely as a grammatical concession, since early compilers already allowed it.

That's why East const exists. John Kalb popularized it, building on earlier work by Dan Saks, who wrote extensively about untangling C++ declarations. Nobody deliberately created two equivalent spellings. They fell out of the grammar because it was convenient and wouldn't break existing code.

const int* p;   // pointer to const int; change the pointer, not the value
int* const p;   // const pointer to int; change the value, not the pointer

The position of const relative to the asterisk matters: to the left of the asterisk, it becomes part of the specifier sequence and qualifies what the pointer points to.

To the right of the asterisk, it becomes part of the declarator and qualifies the pointer itself. This follows the original design principle that declarations should resemble the expressions that will later use the variable. That works nicely for int* p; for int (*f)(int), it's just a cruel joke. Adding const only makes an already complicated grammar harder to read.

And once again, there's no way to fix it. C++ inherited the parsing rules for const from C, and they're effectively set in stone. Changing them would break both C and four decades of code written in both languages. So const looks like a lock on a door, but it's really more like a "Please do not enter" sign with the text facing the door.

The zoo of integer types

How many integer types does C++ have? Around fifty, if you count the fixed-width aliases. And to make things more interesting, not all of them have a fixed size—the actual size depends on the compiler and the target platform.

bool                // yes, `bool` is also an integer (integral) type

char                // a SEPARATE type
signed char         // a SEPARATE type
unsigned char       // a SEPARATE type, there are three different types, not two

char8_t             // C++20
char16_t            // C++11
char32_t            // C++11
wchar_t

short
unsigned short
int
unsigned int
long
unsigned long
long long               // C++11
unsigned long long      // C++11

short, short int, signed short, signed short int       // 4 spellings → 1 type
int, signed, signed int                                // 3 spellings → 1 type
long, long int, signed long, signed long int           // 4 → 1

long long, long long int, signed long long, signed long long int  // 4 → 1
unsigned, unsigned int                                            // 2 → 1

int8_t   int16_t   int32_t   int64_t        // exact width (optional)
uint8_t  uint16_t  uint32_t  uint64_t       // 8 of them

int_least8_t  ... int_least64_t             // minimum width
uint_least8_t ... uint_least64_t            // 8 of them (required)

int_fast8_t   ... int_fast64_t              // fast width
uint_fast8_t  ... uint_fast64_t             // 8 of them

intmax_t  uintmax_t                          // the widest one
intptr_t  uintptr_t                          // under the pointer (optional)

std::size_t        // <cstddef>
std::ptrdiff_t     // <cstddef>
std::sig_atomic_t  // <csignal>
std::wint_t        // <cwchar>
std::streamsize, std::streamoff   // <ios>

int doesn't mean 32 bits. It means at least 16 bits, though it may well be 32. The only guarantee the standard gives is the chain short <= int <= long <= long long. On 64-bit Linux, long is 64 bits. On 64-bit Windows, long is still just 32 bits—all because of backward compatibility (remember that phrase). Use int64_t if you need a guaranteed 64-bit integer. I still don't understand why it carries the _t suffix—it isn't the 1990s anymore. Well, that's one more thing that can't be changed; more on that in the spoiler.

Character types deserve a special mention. There are seven of them, and sooner or later you'll find yourself wondering why a character can be signed or unsigned like an integer, how char differs from signed char and unsigned char (three distinct types, not two), what wchar_t actually is, how std::string differs from std::wstring, and why that difference can suddenly wreak havoc on your encoding. But that's a story for another day.

A history of the language

The type zoo is essentially a paleontological record of every machine C has ever run on. To understand why int isn't 32 bits, it helps to recall the hardware C grew up on.

C emerged in the early '70s, when computer architectures varied wildly. The PDP-11 used 16-bit words, for instance, while the Honeywell systems C was ported to early on used 36-bit words. Some modes even worked with 6- or 9-bit characters. Historically, a C byte was never guaranteed to be 8 bits. In the C standard, CHAR_BIT is the number of bits in the smallest addressable unit of memory, so a machine with CHAR_BIT == 9 is perfectly legal by the language rules.

CDC machines used 60-bit words; some architectures used two's complement, others one's complement. Given all that, Ritchie made the only sensible decision available: don't fix sizes at all. Instead, int simply meant "the machine's natural word type—the one the processor handles most efficiently—but at least 16 bits."

The language guaranteed only minimum ranges and the ordering short <= int <= long <= long long. Actual sizes were left to the target platform. Thanks to that decision, the same source code could compile efficiently on a 16-bit PDP-11, a 36-bit Honeywell, and a dozen other architectures. The fact that int had no fixed size was exactly what made C so portable.

Then 32-bit machines became the norm and int settled at 32 bits. When 64-bit systems arrived, int stayed put. By then the world was already full of code with sizeof(int) == 4 hard-coded into it. Widening int to 64 bits would have broken all of it, to say nothing of countless ABIs.

Microsoft even kept long at 32 bits. Why? A massive existing codebase, an enormous product ecosystem, and millions of users. Or, to put it simply: backward compatibility.

Untold lines of code and the Win32 API itself treated long as a four-byte type, used it interchangeably with int and DWORD, and serialized it to disk and across the network as four bytes. Fixing that was deemed too expensive. So long means different things on different platforms simply because in the late 1990s two ecosystems made different compatibility trade-offs.

int64_t and its _t suffix are essentially an admission that the language failed to make its fundamental integer types predictable. Decades later, a second family of fixed-width types was added in a separate header, <stdint.h>. The _t suffix isn't a relic of the 1990s; it's a relic of the 1970s. It comes from the Unix convention for typedef names, size_t, time_t, wchar_t where names ending in _t are reserved for implementation use. That lets the standard introduce new types without risking collisions with user-defined identifiers.

Non-standard standard library

If my goal were to confuse beginners as much as possible, I'd name things exactly the way the STL does. The most commonly used container is called vector, even though it's really a dynamic array. In the usual sense, a vector is a quantity with a direction. Even Alexander Stepanov, the creator of the STL, later admitted the name was a mistake.

If you need a hash table, you might reach for std::map. But that isn't a hash table—it's a balanced tree with logarithmic lookup. The actual hash table is std::unordered_map. And, spoiler alert, you're better off avoiding that one too, because it's slow. This isn't just a case of a lazy implementation; it's baked into the standard. The guarantees std::unordered_map has to provide leave libstdc++ and libc++ developers little choice but to make it slow.

std::map<std::string, int> ordered;
ordered["banana"] = 1;
ordered["apple"]  = 2;
ordered["cherry"] = 3;

for (auto& [k, v] : ordered)
    std::cout << k << ' ';  // ALWAYS: apple banana cherry, 
                            // in ascending order by key

std::unordered_map<std::string, int> hashed;
hashed["banana"] = 1;
hashed["apple"]  = 2;
hashed["cherry"] = 3;

for (auto& [k, v] : hashed)
    std::cout << k << ' ';  // arbitrary order; 
                            // it depends on the hash and buckets

std::unordered_map<std::string, int> m;
m.insert({"key", 1});
m.insert({"key", 2});  // It DIDN'T overwrite it but returned {iterator, false}
std::cout << m["key"];  // 1, not 2

m.insert_or_assign("key", 2);  // Starting with C++17, this will be overwritten
std::cout << m["key"];         // 2
m["key"] = 2;                  // or just for the sake of it

The standard mandates separate chaining with nodes, and unordered_map must guarantee that references and pointers to elements stay valid across insert and erase, the erased element aside. That means not even a rehash may invalidate a pointer to an existing element.

This is only possible if each element is allocated separately on the heap (std::pair<const Key, Value> plus a pointer to the next element) and each bucket is implemented as a linked list of such elements. In other words, what the standard describes isn't a "hash table in an array" but an "array of pointers to lists scattered across the heap." And that's not the only surprise lurking in the standard library. Here's another:

std::unordered_map<std::string, int> m;
if (m["key"] == 0) { }   // if the key did NOT exist, it was just added
                         // with a default value of 0.
                         // The "if the key exists" check created it.

The operator[] silently inserts the default value for a missing key, so check whether it exists using find/contains, not []. It's a small detail, but beginners stumble over this pitfall all the time.

Then there's empty() that sounds like it should clear the container, but it simply tells you whether the container is empty. You'd expect it to be called is_empty(), but it's not. Meanwhile, remove() doesn't actually remove anything; it simply moves matching elements to the end and returns an iterator. We still need to erase them using the erase-remove idiom. There are also std::stoi, std::stol, std::stoll, std::stof, std::stod, and std::stold, and devs just need to know what they are. Do you know?

Is it really standard?

To understand why the standard library sometimes seems designed to work against developers, it helps to remember that it was created by a mathematician. Alexander Stepanov spent decades developing the concept of generic programming, built on the idea that algorithms should depend on abstract type requirements rather than concrete data structures.

Before C++, he explored the approach in Scheme, then in Ada with David Musser. He eventually moved to C++, where he found that templates—originally designed for an entirely different purpose—were powerful enough to express all of his ideas. In 1993–1994 he brought the result of that work to the language's committee, and in a remarkably rare feat, he got nearly all of it into C++98 virtually unchanged.

That's where vector comes from. In Scheme's computing model, a vector was a one-dimensional contiguous array, so the name made perfect sense to Stepanov. People later realized array would have been a better fit, but by then vector had already made its way into the draft standard and countless codebases. Renaming it was no longer an option—the same story we keep running into throughout C++.

map has a similar history. The name accurately describes the abstraction: a mapping from keys to values. The trouble is that many developers come from Java or Python, where map or dict normally implies a hash table, so they instinctively expect the same behavior. When C++11 finally introduced a real hash table, the obvious name, hash_map, was already off the table—incompatible vendor-specific implementations from SGI, Microsoft, Dinkumware, and others had claimed it years earlier. Rather than break that entire ecosystem, the committee settled on the only unclaimed, if rather awkward, name available: unordered_map. The ugly name isn't so much a design mistake as another scar left by C++'s commitment to backward compatibility.

Don't forget about ...value

And to cover all the bases, there are lvalue, rvalue, glvalue, prvalue, and xvalue. Ring any bells?

In some cases std::move makes a copy, and what you actually need is std::move_if_noexcept. While we're on the subject of move semantics, std::move has been badly named from the very start. It doesn't move anything at all! All it does is cast its argument to an rvalue reference, making it eligible to bind to a move constructor or a move assignment operator. It really should have been called rvalue_cast. Then again, come to think of it, C++ probably doesn't need yet another cast.

Not every lvalue is an xvalue

C had just two value categories: lvalues and rvalues. C++11 introduced move semantics, and two were no longer enough. The language had to distinguish between "a named object you shouldn't touch" and "a temporary whose value you may take." Those are really two independent properties, and their combinations yield five value categories. That's where xvalue—short for eXpiring value, an object that has identity but whose value you may safely move from... comes in.

To mark an object as an xvalue, the language needed a dedicated operation. rvalue_cast would have been the obvious name, but the committee didn't want to introduce yet another cast. Instead, Howard Hinnant and the other designers picked a name that reflects intent rather than mechanics. So whenever you write std::move, read it as "I'm done with this object—you can take its value now."

The standard library also has a second std::move—one that actually moves elements. So, don't confuse the std::move that moves things with the std::move that doesn't. Someone once even showed me a 70-page PDF explaining when and how to use each one correctly. Too bad I don't remember its title.

That's without even getting into names of C++ idioms. Do you know what RAII is? It stands for Resource Acquisition Is Initialization, but the name points to the least important part of the idiom. RAII is really about the opposite: automatically releasing a resource in the destructor when an object goes out of scope. If anything, it should have been called CADR (Constructor Acquires, Destructor Releases) because that's what the idiom is actually about, not the fact that a constructor acquires a resource.

void process() {
    FileHandle file("data.txt"); // we opened it

    if (nothing_to_do())
        return;            // early exit, the file is closed automatically

    might_throw();         // an exception was thrown, he file is STILL closed
}                          // regular scope end, the destructor closed the file

Take CRTP as another example. Have you ever stopped to think about what the name actually means? CRTP stands for Curiously Recurring Template Pattern, and the name doesn't describe what the pattern does at all. Instead, it reflects the author's reaction: they kept running into this same template pattern in different codebases and found it curious enough to give it that name.

Modern C++

Have you heard that learning modern C++ is a must? However, a simple Google search for "what is modern C++" yields results from over two decades ago.

Effective Modern C++ by Scott Meyers (2014), with the subtitle "42 specific ways to improve your use of C++11 and C++14"

Modern C++ Design: Generic Programming and Design Patterns Applied

The Modern C++ Challenge

Modern C++: Efficient and Scalable Application Development

C++11 was the first release people called modern C++. It brought smart pointers, lambdas, and move semantics. Then came C++14, C++17, C++20, and C++23, each claiming to be the latest—and therefore the new "modern C++." The result is that even the bestselling Effective Modern C++ is dated and, in places, no longer effective. Meanwhile, much of the industry still lives in the C++17 era, because nobody is eager to rewrite millions of lines of production code just to make it "even more modern." The risk simply isn't worth it.

So developers have to be fluent in every major version of the standard—and trust me, they differ. The legacy code at your job targets one dialect, the new codebase another, the textbook a third, and the YouTube tutorial a fourth. And none of them count as "modern" anymore.

Errors that don't fit on the screen

When you finally get around to compiling something, you're greeted by the error messages. C++ can turn a single misplaced character into a thousand lines of nearly unreadable garbage, with the real cause buried somewhere in the middle. By the time you dig it out, your brain has already given up, because half the output is just the standard library's internals spilling across the screen.

Template instantiation errors read like an unreadable dialect of Chinese written entirely in angle brackets. They stretch so far horizontally that they won't fit on a 4K monitor. I'm not joking—I only came to appreciate ultrawide displays after staring at those errors. At some point I even turned off line wrapping, because it just made them harder to read. It's no wonder so many C++ developers end up with ultrawide monitors, glasses, and chronic neck pain.

Why errors are so wordy

A template isn't code. When you supply particular types, the compiler instantiates it by substituting those types throughout the definition. Only then does it check the resulting code for errors. It instantiates the entire template, replacing every occurrence with your type.

Now imagine the real problem lies deep inside an algorithm, because your type doesn't satisfy sort's requirements. By the time the compiler spots the error, it has already expanded ten layers of templates, and the only route back to the root cause is to dump the whole instantiation chain onto your screen. In a sense, this is duck typing at compile time. The template simply works if the operations inside it are valid. The downside is that duck typing brings the same style of error reporting: the problem doesn't surface where you made the mistake, but somewhere deep inside someone else's library, where the operation is actually used. The template has no idea what it's calling there—it isn't code yet; it only checks whether what it's handed fits.

For thirty years, templates had no way to express their requirements. You simply couldn't write "this template requires a comparable type," because under duck typing the requirements are always implicit.

The compiler had no way to say "you've violated requirement X," because no such requirement existed anywhere. The best it could do was drag you to line 4212 somewhere deep inside <algorithm> and point out that your type doesn't define operator<. And to convince you that's really where the trouble started, it had to dump the entire template instantiation stack on you.

Concepts... the feature that finally lets you name those requirements—trace their roots back to Alexander Stepanov's informal concepts from the late 1980s. They were originally slated for C++0x, but the committee pulled them from C++11 because the design was judged too complex. They finally landed in C++20, which is why we now write requires.

Zero-maybe abstractions

For the past twenty years, C++ has marketed itself as the language of zero-cost abstractions, but every abstraction has a cost. Take std::unique_ptr: it's slower than a raw pointer, because it has a non-trivial destructor, and under the Itanium ABI that means it can't be passed in a register. It can only go on the stack, whereas a raw pointer would land in a register.

And this isn't just about smart pointers. The same applies to any type with a non-trivial destructor: shared_ptr, string, vector—they all get passed by value through memory for the same reason. Move semantics aren't free either. The real cost comes from the destructor. Because C++ uses non-destructive moves, the moved-from object still has to run its destructor, and carefully written manual code can outperform the equivalent move-based implementation.

The regular expressions in the standard library are notorious as one of the worst implementations around. In some cases they run tens or even hundreds of times slower than the alternatives, and merely including <regex> can easily add about a second of compile time to every translation unit.

unordered_map isn't especially fast either: it's cache-unfriendly, and when performance really matters, developers often reach for flat_hash_map from Google's Abseil or F14 from Facebook's Folly instead. Spot the pattern? Plenty of C++ features could be substantially faster, but they probably never will be. Making them faster would break ABI compatibility—and that brings us to the main point.

Compatibility at a cost of everything else

All the complaints I've mentioned—from awkward names and slow containers to the static zoo and invisible copies—ultimately lead to the same conclusion. People think C++ puts performance above everything else, but in reality, its highest priority is backward compatibility. Performance comes second; developer ergonomics come second; the overall programming experience comes second. Everything comes second.

That commitment to compatibility is exactly what turned the language into the abomination it is today. You can't rename vector because it would break billions of code lines. You can't make unordered_map significantly faster because it would change the ABI. And you certainly can't introduce destructive move semantics—the opportunity passed more than a decade ago, and breaking existing code is simply off the table. Every wart in the language is a fossilized consequence of some long-forgotten design decision. You can't remove it because something already depends on it: someone's library, game engine, application, or entire build pipeline.

Ironically, the very thing people criticize C++ for is also the reason it powers such a large part of software over the world. Backward compatibility is both the language's greatest flaw and the key to its survival. Code you wrote twenty years ago will often still compile today—with a bit of tweaking and the occasional ritual sacrifice. Even an abandoned library from 2008 can link to a modern application. For industries like game development, where rewriting a codebase could cost dozens of person-years, this isn't a drawback—it's the load-bearing wall.

What about Rust, though?

People have been asking me in the comments to share my thoughts on Rust. Hopefully we can avoid turning this into another language war—it's simply a different language.

From a design standpoint, Rust is far better. It ships with a standard compiler, a standard build system, and a standard package manager, and there are no header files. The best compiler error messages I've ever seen, sensible defaults, no implicit conversions, proper UTF-8 support, sum types, and compile-time memory safety. Many of the problems C++ has yet to solve—and likely won't solve even in the next decade—have already been handled in Rust.

Being better designed doesn't automatically make it the right choice, though. Game development thrives on rapid iteration, creative chaos, and "let's see what happens if we try this." Rust doesn't really accommodate that style—and, to be fair, neither does modern C++, no matter how many features each new standard piles on. That's one reason game development has shifted more and more toward scripting languages, DSLs, and declarative programming.

At its core, Rust prioritizes correctness and discipline, and that creates a fundamental tension. A growing number of game projects have started in Rust only to move away from it for exactly that reason. Then there's the ecosystem. However you look at it, CUDA, game engines, tooling, and billions upon billions of lines of existing code all revolve around C++. And that isn't going to change anytime soon.

The worst/best programming language of all times?

C++ is a terrible language. It's verbose where it shouldn't be and silent where it shouldn't be. It comes with a zoo of types, misleading keywords, invisible copies, unreadable error messages, and a build system straight out of hell.

Writing good C++ takes an encyclopedic knowledge of the exceptions to the rules—and once you've memorized those, you still have to learn the exceptions to the exceptions. Yet C++ is very much alive, and it's likely to stay that way for decades. It has tremendous momentum, and it's one of the few languages that puts backward compatibility first, possibly at the expense of everything else. That single decision made C++ both unbearable and irreplaceable. Half the software world runs on it today, and it will keep running on it for a long time, whether I like it or not.

I write in this terrible language, romanticizing its complexity to prove to myself that I'm smart. And I'll keep writing in it, because in my field it's still the only language that delivers the performance I need. It's become a load-bearing wall. Replacing that wall in an occupied, constantly renovated building isn't as simple as redesigning a few rooms in some fashionable language. You'd have to tear the whole building down and rebuild it from scratch while living in a shed for the next couple of years.

So yes, C++ is a terrible language. Now fire up your terrible IDE and get back to coding in the worst programming language in the entire world!

Want to learn more?

The PVS-Studio team values the C++ community and doesn't miss an opportunity to talk more about how to improve workflows using static code analyzers. Here are some useful resources:

How catch-block selection works in exception handling
Silent foe or quiet ally: Brief guide to alignment in C++ (part 1, part 2, part 3)
How far does lookup see in C++?

Avoid adding new library to project: 10-year retrospective

Unicorn Developer — Wed, 02 Sep 2026 13:24:15 +0000

Everyone is trying to speed up software development by building their solutions using "bricks" like third-party components or libraries. However, we forget what problems they may trigger. Today, I'll try to explain why it's worth thinking twice before adding a new dependency to a project. The article is a remake that I've decided to write after realizing that my old recommendation is still relevant.

Ten years ago, I've said about it in the compilation of recommendations "The Ultimate Question of Programming, Refactoring, and Everything."

Many people criticized this point, which made me doubt whether I was right. After all, the world doesn't stand still: progress marches on. Developers put apps together like LEGO bricks, and plus, package managers have evolved. It's convenient for everyone, and everyone seems happy. So why am I bringing up my doubts?

I've not mentioned this topic again in later articles, including 60 terrible tips for a C++ developer (2023), but I've been watching how things have changed for several years, and I can say that my position has returned to what it was before: whenever possible, it's still better to avoid to add new libraries that spawn more dependencies.

And I think I was right, although to be honest, I've chosen not the best way to present this or not the best examples. Plus, the earlier arguments omit an important point that has come to the fore in the context of secure software development and certification. Actually, there is one, number 4, but it sounds too trivial. So let me try again.

First, I'll show an older, slightly reduced version of the text, and then I'll reinforce it with new arguments and thoughts. Overall, everything I've said still stands, and I ask that you think about what you've read before we get into another round of arguments in the comments :)

Chapter 41 from the 2016 collection of tips

Suppose you need to implement an X functionality in your project. Theorists of software development will say that you have to take the already existing library Y, and use it to implement the things you need. In fact, it is a classic approach in software development, reusing your own or others' previously created libraries (third-party libraries). And most programmers use this way.

However, those theorists in various articles and books, forget to mention what hell it will become to support several dozen third-party libraries in about 10 years.

I strongly recommend avoiding adding a new library to a project. Please don't get me wrong. I am not saying that you shouldn't use libraries at all, and write everything yourself. This would be insufficient, of course. But sometimes a new library is added to the project at the whim of some developer, intending to add a little cool small "feature" to the project. It's not hard to add a new library to the project, but then the whole team will have to carry the load of its support for many years.

Tracking the evolution of several large projects, I've seen quite a lot of problems caused by a large number of third-party libraries. I will probably enumerate only some of the issues, but this list should already provoke some thoughts:

Adding new libraries promptly increases the project size. In our era of fast Internet and large SSD drives, this is not a big problem, of course. But, it's rather unpleasant when the download time from the version control system turns into 10 minutes instead of 1.
Even if you use just 1% of the library capabilities, it is usually included in the project as a whole. As a result, if the libraries are used in the form of compiled modules (for example, DLL), the distribution size grows very fast. If you use the library as source code, then the compile time significantly increases.
Infrastructure connected with the compilation of the project becomes more complicated. Some libraries require additional components. A simple example: we need Python for building. As a result, in some time you'll need to have a lot of additional programs to build a project. So the probability that something will fail increases. It's hard to explain, you need to experience it. In big projects something fails all the time, and you have to put a lot of effort into making everything work and compile.
If you care about vulnerabilities, you must regularly update third-party libraries. It would be of interest to violators, to study the code libraries to search for vulnerabilities. Firstly, many libraries are open-source, and secondly, having found a weak point in one of the libraries, you can get a master exploit to many applications where the library is used.
One the libraries may suddenly change the license type. Firstly, you have to keep that in mind, and track the changes. Secondly, it's unclear what to do if that happens. For example, once, a widely used library softfloat moved to BSD from a personal agreement.
You will have troubles upgrading to a new version of the compiler. There will definitely be a few libraries that won't be ready to adapt for a new compiler, you'll have to wait, or make your own corrections in the library.
You will have problems when moving to a different compiler. For example, you are using Visual C++, and want to use Intel C++. There will surely be a couple of libraries where something is wrong.
You will have problems moving to a different platform. Not necessarily even a totally different platform. Let's say, you'll decide to port a Win32 application to Win64. You will have the same problems. Most likely, several libraries won't be ready for this, and you'll wonder what to do with them. It is especially unpleasant when the library is lying dormant somewhere, and is no longer developing.
Sooner or later, if you use lots of C libraries, where the types aren't stored in namespace, you'll start having name clashes. This causes compilation errors, or hidden errors. For example, a wrong enum constant can be used instead of the one you've intended to use.
If your project uses a lot of libraries, adding another one won't seem harmful. We can draw an analogy with the broken window theory. But consequently, the growth of the project turns into uncontrolled chaos.
And there could be a lot of other downsides in adding new libraries, which I'm probably not aware of. But in any case, additional libraries increase the complexity of project support. Some issues can occur in a fragment where they were least expected to.

Again, I should emphasize; I don't say that we should stop using third-party libraries at all. If we have to work with images in PNG format in the program, we'll take the LibPNG library, and not reinvent the wheel.

But even working with PNG we need to stop and think. Do we really need a library? What do we want to do with the images? If the task is just to save an image in *.png file, you can get by with system functions. For example, if you have a Windows application, you could use WIC. And if you're already using an MFC library, there is no need to make the code more sophisticated, because there's a Cimage class (see the discussion on Stack Overflow). Minus one library—great!

Recommendation

Keep resisting the temptation to add new libraries to your project. Add it only when you're sure that libraries are really indispensable.

What to do? Here are some possible maneuvers:

Check your system's API or one of the libraries you're already using whether it has this functionality.
Implement the functionality by yourself if it's not so huge instead of using only a very small part of the library's functionality. The argument that "I add the whole library and maybe it'll be handy someday in the future" isn't worth the trouble. Usually it doesn't happen. Yes, programmers are too focused on versatility, which often isn't needed.
Choose the simplest library that meets your requirements and helps you solve the task. As mentioned above, don't choose a more powerful library "just in case."
Just wait a moment and think over before adding the library. Have some tea, take a break, and discuss the task with your colleagues. You may find that you don't need a third-party library after all and can solve the problem another way.

P.S. Many people won't like what is said here. For example, I recommend using WinAPI rather than a non-portable universal library. It kind of locks the project into a single operating system and complicates the further program migration—and I can't agree with this point. This idea to migrate the program to another OS is just sitting in the developer's head, but in reality, management may never set such a goal at all, or the project will fail due to excessive complexity and versatility, even before it gains popularity and the need for porting arises. Also, don't forget item (8) on the list of issues provided above.

The end of the old post, but not the end of the story

Everything said in the original is still true today, although the emphasis has shifted. Today, we need to focus on controlling an overly gigantic codebase when establishing secure development processes. Now it is coming to the forefront. Point number 4 has become truly urgent.

Adding libraries in your projects triggers the creation of transitive dependencies. This means that the library uses other libraries, which in turn use other libraries, and so on. Now the required 10 libraries for your projects, in reality, turn into 100s being used. In some languages, such as C++, this is not very noticeable, whereas when developing in JavaScript, Java, or Python, huge chains of dependencies quickly emerge.

If a vulnerability is detected in one of these libraries, it means your application is also potentially vulnerable. It doesn't matter to the user whether your app is vulnerable because of your own code or third-party code.

Of course, the vulnerability in a particular library doesn't automatically mean that your application is vulnerable as well. Dangerous functions may simply never be called, or work with data that won't cause any problems. This means that the vulnerability isn't the primary attack target.

However, that doesn't make it much easier. After all, we need to be sure that the vulnerability can't be exploited. And in reality, it can be really hard work.

So, if you think about your project's reputation, it's worth tracking all new vulnerabilities in all components that are used directly or indirectly, for example, using Software Composition Analysis (SCA) tools for this purpose.

If you have composition analysis tools, what's the problem with having a large number of dependencies? The more there are, the greater the chance that someone will find a new vulnerability and exploit it.

That's not all. Vulnerabilities may be caused not only by a random bug, but can also be the intentional act. For example, supply chain attacks become more well-known problem: attackers use various methods to inject undocumented features into various open-source libraries. For example, they contribute some changes and enhancements for a while, build up a positive reputation, and then sneak a backdoor into the code. Transitive dependencies open the door to exploit a large number of applications at once. So, the more third-party libraries you use, the higher the risk of supply chain attacks.

Another option of such an attack has emerged related to AI-generated code (GenAI). AI can hallucinate in the names of the required packages. It's clear that hallucinations follow certain patterns, and malicious actors will not miss the opportunity and use it: they create and publish compromised packages with names that GenAI is most likely to hallucinate. It sounds far-fetched, but it works, and such attacks have already been used. They came to be known as slopsquatting.

The next topic is static analysis. From a security standpoint, you should review your own code plus all third-party code. Few people do this, since most people tend to focus only on viewing their own code. But anyone who stops to think about it is faced with a huge amount of work.

However, if you want to conduct certification testing on your project, it makes no difference whether you wrote the code yourself or obtained it from an external source. Do you use third-party code? It's yours now. Take responsibility for it. That makes sense: it doesn't matter who wrote the code that makes the app vulnerable.

In practice, it may be impractical for a single company to perform a static analysis of all borrowed code. This has given rise to trusted repository projects and consortia of companies for the conjoint analysis of borrowed components. One approach is to analyze the initial modules that make up the attack surface. Here again, the problem of defining this surface arises. I won't go into detail here.

Conclusion

Of course, it won't impact on our habit to eagerly add third-party components into the project. I'm not calling to change that; it'd be counterproductive. However, I still want you to be aware of the potential problems you might encounter.

I think you can try a little bit enhance your code review process by controlling (or discussing) all libraries that are added. Let the developer explain why they really need yet another library. Perhaps, if they have known this during the development phase, they would have chosen a different approach to solving the problem or used the functionality of another library that was already included in the project. In short, try to avoid adding new libraries to the project. Maybe it'll actually work out for you someday :) And you will thank me later.

Ideally, it would be a good idea to audit your project from time to time to check whether all project-related libraries are being used. I've seen cases where, while porting a large C++ application from Win32 to Win64, it turned out that about 10 libraries weren't being used at all. At the same time, resources had been spent for many years on maintaining them within the project. Conducting such an audit may not be easy, but you might be able to pull it off.

We checked the source code of VS Code

Unicorn Developer — Tue, 01 Sep 2026 06:33:05 +0000

No more tiptoeing, we can finally say it out loud: we've released a static code analyzer for JavaScript and TypeScript. So naturally, it's time to send it out into the wild and see what it catches in the source code of Visual Studio Code, an open-source project most developers know all too well. Here's what turned up.

Before we start

This section is for anyone who isn't familiar with our article format, so you know what to expect.

At PVS-Studio, we build a static code analysis tool. Basically, a static analyzer is a program that looks for logical errors in the source code of other programs. For this kind of article, we pick a popular open-source project, run our analyzer on it, and share what we find with our readers, as well as with the project's developers, by filing issues and pull requests.

With the current release, we're adding a new analyzer for JavaScript and TypeScript. Right now it runs on a basic set of diagnostic rules, but it's already capable of catching real errors and flagging suspicious code.

To show it tackling something real, we picked a project pretty much everyone's heard of, Visual Studio Code. It combines JavaScript and TypeScript code, and the codebase is quite large, so we were curious to see what our newcomer would find in it.

We ran the analysis on release version 1.128.0, the latest version at the time of writing, at commit fc3def677. We cloned the repo, ran the analysis, and once it finished, picked out the most interesting results. Now for the results.

Accessing an array in a strange way

In this section, and in the ones that follow, you'll see a code snippet containing either an outright error or code that looks off and is worth a second look, followed by the PVS-Studio warning and a link to the source in the repository. Right after that, we'll explore what's wrong with the actual code.

The first error for today is a rather extravagant way to access an array:

....
const diffs = changes.map(splice => {
    return [splice[0], splice[1], splice[2].map(....)] 
             as [number, number, CellViewModel[]];
});
....
for (let i = 0; i < diffs.length; i++) {
  const diff = diffs[0];                 // <=
  if (diff[0] + diff[1] <= primarySelectionIndex) {
    delta += diff[2].length - diff[1];
    continue;
  }
  if (diff[0] > primarySelectionIndex) {
    endSelectionHandles = [primaryHandle];
    break;
  }
  if (diff[0] + diff[1] > primarySelectionIndex) {
    endSelectionHandles = [this._viewCells[diff[0] + delta].handle];
    break;
  }
}
....

The PVS-Studio warning: V7016 Suspicious access to an element of the 'diffs' object by a constant index inside a loop. notebookViewModelImpl.ts 252

Here, we have an array being built, followed by an attempt to loop through it. Why an attempt? The i index is never actually used within the array, instead, the line marked with the comment // <= always pulls the element at index 0. As a result, on every single iteration, checking diff means dealing with the first element of the diffs collection.

Judging by the snippet itself, that wasn't the intent. The plan was clearly to check each i-th element, but a typo is a typo.

This is a recurring pattern across other languages too. Our Java analyzer, for instance, has caught similar issues before.

So we're moving on.

Checking the wrong thing

....
let lastValueAtPosition: boolean | undefined = undefined;
let lastValueOnLine: boolean | undefined = undefined;
timeouts.add(autorun(reader => {
  const newValueAtPosition = 
          s.source.isPresentAtPosition(args.position, reader);
  const newValueOnLine = 
          s.source.isPresentOnLine(args.position.lineNumber, reader);
  if (   lastValueAtPosition !== undefined 
      && lastValueAtPosition !== undefined) {  // <=
    if (!lastValueAtPosition && newValueAtPosition) {
      trigger(s.property, s.source, 'positional');
    }
    if (!lastValueOnLine && newValueOnLine) {
      trigger(s.property, s.source, 'line');
    }
  }
  lastValueAtPosition = newValueAtPosition;
  lastValueOnLine = newValueOnLine;
}));
....

The PVS-Studio warning: V7001 The operands of the '&&' operator in the 'lastValueAtPosition !== undefined && lastValueAtPosition !== undefined' expression are equivalent. editorTextPropertySignalsContribution.ts 152

The code has two variables, lastValueAtPosition and lastValueOnLine, both typed as boolean or undefined. And in the arrow function they're passed into, the intent was to first check that neither one is undefined, and only then treat them as boolean values.

There's a typo in the condition the analyzer flagged: the binary expression && uses identical operands. As a result, lastValueOnLine never gets checked against undefined, meaning the second nested if statement can behave incorrectly.

Shady self-assignment

The assignment operator comes with its share of sneaky typos, here's the first one.

The first snippet:

swapChildren(from: number, to: number): void {
  from = validateIndex(from, this.children.length);
  to = validateIndex(to, this.children.length);
  if (from === to) {
    return;
  }
  this.splitview.swapViews(from, to);
  // swap boundary sashes
  [this.children[from].boundarySashes, 
   this.children[to].boundarySashes] = 
  [this.children[from].boundarySashes, 
   this.children[to].boundarySashes]; // <=
  // swap children
  [this.children[from], this.children[to]] = 
    [this.children[to], this.children[from]];
  this.onDidChildrenChange();
}

The PVS-Studio warning: V7005 The expression '[this.children[from].boundarySashes, this.children[to].boundarySashes]' is assigned to itself. gridview.ts 575

In this code, the goal was to use destructuring to swap the values of this.children[from].boundarySashes and this.children[to].boundarySashes. Destructuring is a handy way to do this kind of swap without introducing a third variable. But for it to actually work, the values on the right side of the assignment needed to be in the opposite order. As it stands, the // swap boundary sashes comment doesn't match what the code actually does.

By the way, a similar swap happens further down, with different values, and that one doesn't have this typo.

The second snippet:

export class LanguageModelTextPart implements vscode.LanguageModelTextPart2 {
  value: string;
  audience: vscode.LanguageModelPartAudience[] | undefined;  

  constructor(value: string, audience?: vscode.LanguageModelPartAudience[]) {
    this.value = value;
    audience = audience;  // <=
  } 

  toJSON() {
    return {
      $mid: MarshalledId.LanguageModelTextPart,
      value: this.value,
      audience: this.audience,
    };
  }
}

The PVS-Studio warning: V7005 The variable 'audience' is assigned to itself. extHostTypes.ts 4033

Another assignment typo, but in a different context this time. There's a constructor parameter named audience and a class field also named audience. When assigning a value to the audience field, the code forgot the this keyword. As a result, the audience field never gets initialized.

The third snippet:

export class ServerInstalledExtensionsView extends ExtensionsListView {
  override async show(query: string): Promise<IPagedModel<IExtension>> {
    query = query ? query : '@installed';
    if (....) {
      query = query += ' @installed';  // <=
    }
    return super.show(query.trim());
  }
}

The PVS-Studio warning: V7005 The variable 'query' is assigned to itself. extensionsViews.ts 1310

This one's similar, but it's hardly an error, more of a typo or an odd use of the += operator. The += operator already assigns the new value to query on its own, so the query = .... part in front of it is redundant.

In this particular spot, it's very unlikely to cause any real trouble. But the same kind of typo, if it landed on a plain = assignment meant for a different variable, could actually cause problems. And beyond that, a new developer reading this code would have to stop and figure out whether there's a real bug here or whether the redundant assignment is just harmless. That's reason enough not to leave code like this as is.

There're similar warnings in the project:

V7005 The variable 'filePath' is assigned to itself. fileLoading.ts 31
V7005 The expression 'tunnelProperties.privacy' is assigned to itself. tunnelModel.ts 773
V7005 The variable 'value' is assigned to itself. task.ts 75

HTTPS or HTTPS?

private onFocusChanged(event: ITableEvent<ITunnelItem>) {
  if (event.indexes.length > 0 && event.elements.length > 0) {
    this.lastFocus = [...event.indexes];
  }
  const elements = event.elements;
  const item = elements && elements.length ? elements[0] : undefined;
  if (item) {
    this.tunnelViewSelectionContext.set(
      makeAddress(item.remoteHost, item.remotePort));
    this.tunnelTypeContext.set(item.tunnelType);
    this.tunnelCloseableContext.set(!!item.closeable);
    this.tunnelPrivacyContext.set(item.privacy.id);
    this.tunnelProtocolContext.set(item.protocol === TunnelProtocol.Https 
                                                  ? TunnelProtocol.Https 
                                                  : TunnelProtocol.Https); // <=
    ....
  }
}

The PVS-Studio warning: V7012 [CWE-1041] The conditional expression 'item.protocol === TunnelProtocol.Https ? TunnelProtocol.Https : TunnelProtocol.Https' always returns the same value. tunnelView.ts 997

Here, the analyzer flags that both branches of the ternary return the same value, TunnelProtocol.Https. We checked TunnelProtocol, and sure enough, the else branch should be returning TunnelProtocol.Http instead.

Interestingly, we'd already flagged this one ourselves, and while double-checking it before writing this article, we noticed that a few days after our check, one of VS Code's users had spotted the same bug independently. Here's a link to their pull request. This is a good example of static analysis catching errors before they make it into the master branch.

Another warning for V7012 also flagged the following snippet:

....
if (this.selection.endColumn <= this.targetPosition.column) {
  // The target position is after the selection's end position
  this.targetSelection = new Selection(
    this.targetPosition.lineNumber - this.selection.endLineNumber 
      + this.selection.startLineNumber,
    this.selection.startLineNumber === this.selection.endLineNumber 
      ? this.targetPosition.column - this.selection.endColumn 
          + this.selection.startColumn                                
      : this.targetPosition.column - this.selection.endColumn 
        + this.selection.startColumn,                        // <=
    this.targetPosition.lineNumber,
    this.selection.startLineNumber === this.selection.endLineNumber ?
      this.targetPosition.column :
      this.selection.endColumn
  );
}
....

The PVS-Studio warning: V7012 [CWE-1041] The conditional expression always returns the same value. dragAndDropCommand.ts 86

Here too, the analyzer points out identical expressions in the branches of the ternary operator, but this one isn't as clear-cut as the last. It looks like the then and else branches probably aren't meant to be identical, but what one of them should actually contain is anyone's guess. This is a case where the fix should come from someone who fully understands what this code is meant to do.

Unreachable condition

....
const lineCount = model.getLineCount();
const endLine = lineNumber === lineCount;
const prevLineEmptyOrIndented = 
        lineNumber > 1 && isLineEmptyOrIndented(lineNumber - 1);
const nextLineEmptyOrIndented = 
        !endLine && isLineEmptyOrIndented(lineNumber + 1);
const currLineEmptyOrIndented = isLineEmptyOrIndented(lineNumber);
const notEmpty = !nextLineEmptyOrIndented && !prevLineEmptyOrIndented;
// check above and below. if both are blocked, display lightbulb in the gutter.
if (!nextLineEmptyOrIndented && !prevLineEmptyOrIndented && !hasDecoration) {
  this._gutterState.set(....);
  this.renderGutterLightbub();
  return this.hide();
} else if (prevLineEmptyOrIndented || endLine || 
          (prevLineEmptyOrIndented && !currLineEmptyOrIndented)) {    // <=
    effectiveLineNumber -= 1;
}
....

The PVS-Studio warning: V7018 The expression 'prevLineEmptyOrIndented || (prevLineEmptyOrIndented && ...)' is redundant and always evaluates to 'prevLineEmptyOrIndented'. lightBulbWidget.ts 373

In this snippet, the analyzer caught an odd pattern in the condition. The warning itself points out that if you set aside the second subcondition, || endLine, what's left is prevLineEmptyOrIndented || (prevLineEmptyOrIndented && ...). Once the condition is reduced to that form, it's clear that we'll either never reach the second part, or it won't evaluate to true anyway.

Forgotten return

....
if (focusedRepository) {
  ....
  // Resource Groups
  const resourceGroups: string[] = [];
  for (const resourceGroup of focusedRepository.provider.groups) {
    resourceGroups.push(
      `${resourceGroup.label} (${resourceGroup.resources.length} resource(s))`);
  }

  focusedRepository.provider.groups.map(g => g.label).join(', '); // <=
  content.push(
            localize(
              'state-msg6', 
              "Resource groups: {0}", resourceGroups.join(', ')));
}
....

The PVS-Studio warning: V7010 [CWE-252] The return value of function 'join' is required to be utilized. scmAccessibilityHelp.ts 108

The problem is that the result of calling join is never stored anywhere. Because of that, the line calling it is doing literally nothing.

Bugs like this usually come from one of two things: either a developer just forgets to write the assignment, or there's confusion about how a method actually works, whether it mutates the object in place or returns a new value. Since the code above shows the correct usage of join, we're leaning toward the first explanation.

Identical operands

The first snippet:

....
if (gapOriginalLength > 0) {
  const gapStartOffset = 
    nesOffset + lastChange.originalStart + lastChange.originalLength;
  const gapStartPos = textModel.getPositionAt(gapStartOffset);
  const wordRange = textModel.getWordAtPosition(gapStartPos);
  if (wordRange) {
    const wordStartOffset = 
      textModel.getOffsetAt(
        new Position(gapStartPos.lineNumber, wordRange.startColumn));
    const wordEndOffset = 
      textModel.getOffsetAt(
        new Position(gapStartPos.lineNumber, wordRange.endColumn));
    const gapEndOffset = gapStartOffset + gapOriginalLength;
    if (wordStartOffset <= gapStartOffset && gapEndOffset <= wordEndOffset 
        && wordStartOffset <= gapEndOffset 
        && gapEndOffset <= wordEndOffset) {  // <=
      lastChange.originalLength = 
          (change.originalStart + change.originalLength) 
            - lastChange.originalStart;
      lastChange.modifiedLength = 
          (change.modifiedStart + change.modifiedLength) 
            - lastChange.modifiedStart;
      continue;
    }
  }
}
....

The PVS-Studio warning: V7001 The operands of the '&&' operator are equivalent. renameSymbolProcessor.ts 141

Here, the analyzer is pointing at this condition:

   wordStartOffset <= gapStartOffset && gapEndOffset <= wordEndOffset
&& wordStartOffset <= gapEndOffset && gapEndOffset <= wordEndOffset

Since the variable names in this condition are so similar to each other, the issue isn't obvious at a glance. But look closely and gapEndOffset <= wordEndOffset is checked twice in that chain.

That repetition is what makes this potentially risky, since this could be more than just a harmless extra condition. When code has a run of similar-looking lines, variable names, or object names, it's easy to accidentally reference the wrong one. That's exactly the kind of mistake a quick read-through can miss, since the operands of && all look alike here. Hopefully it really is just an unnecessary condition, nothing more.

The second snippet:

....
if (   response.status === 401 
    && text.includes('authorize_url') 
    && jsonData?.authorize_url
) {
  return {
    type: FetchResponseKind.Failed,
    modelRequestId: modelRequestIdObj,
    failKind: ChatFailKind.AgentUnauthorized,
    reason: response.statusText || response.statusText, // <=
    data: jsonData
  };
}
....

The PVS-Studio warning: V7001 The operands of the '||' operator in the 'response.statusText || response.statusText' expression are equivalent. chatMLFetcher.ts 1641

Another one like the last, and it looks like a typo too. Elsewhere in the code, reason is set as follows:

reason: jsonData.message || 'Invalid previous response ID'

Or like this:

reason: jsonData?.message || `token expired or invalid: ${response.status}`

The third snippet:

....
// Notebooks are not supported yet.
if (URI.isUri(variableRef.value)) {
  if (await this.ignoreService.isCopilotIgnored(variableRef.value)) {
    return;
  }
  if (
    variableRef.value.scheme === Schemas.vscodeNotebookCellOutput 
    || variableRef.value.scheme === Schemas.vscodeNotebookCellOutput
  ) {
    return;
  }
  ....
  validReferences.push(variableRef);
  fileFolderReferences.push(variableRef);
  return;
}
....

The PVS-Studio warning: V7001 The operands of the '||' operator are equivalent. copilotcliPromptResolver.ts 136

The variableRef.value.scheme field is compared against the same constant from Schemas. Here are the other candidates in Schemas that this comparison could have been checking against instead:

export const vscodeNotebookCell = 'vscode-notebook-cell';
export const vscodeNotebookCellMetadata = 'vscode-notebook-cell-metadata';
export const vscodeNotebookCellMetadataDiff = 
                  'vscode-notebook-cell-metadata-diff';
export const vscodeNotebookCellOutput = 'vscode-notebook-cell-output';
export const vscodeNotebookCellOutputDiff = 'vscode-notebook-cell-output-diff';
export const vscodeNotebookMetadata = 'vscode-notebook-metadata';
export const vscodeInteractiveInput = 'vscode-interactive-input';

The fourth snippet:

static isEqual(a: Diagnostic | undefined, b: Diagnostic | undefined): boolean {
  if (a === b) {
    return true;
  }
  if (!a || !b) {
    return false;
  }
  return a.message === b.message
    && a.severity === b.severity
    && a.code === b.code
    && a.severity === b.severity
    && a.source === b.source
    && a.range.isEqual(b.range)
    && equals(a.tags, b.tags)
    && equals(a.relatedInformation, 
              b.relatedInformation, 
              DiagnosticRelatedInformation.isEqual);
}

The PVS-Studio warning: V7001 The operands of the '&&' operator are equivalent. diagnostic.ts 99

The expression a.severity === b.severity shows up twice here. It looks odd, but every field of Diagnostic is already checked, so the developers just tacked on a redundant condition.

The exact same thing happens in this next comparison:

V7001 The operands of the '&&' operator are equivalent. keyboardLayoutService.ts 431

To wrap up, a bit more on this group of V7001 warnings:

Every example here comes down to the same question: is the repeated operand just redundant, or is it a real typo? Figuring that out usually eats up more time than it should, which is exactly why this kind of thing shouldn't slip into the code in the first place.

But mistakes like this are genuinely easy to miss during a code review. Unlike a person, a static analyzer never loses focus, which makes it invaluable when working through large amounts of repetitive code. Static analysis pays off in plenty of other situations too, but these examples make its benefits especially clear.

Misleading formatting

if (isResourceMergeEditorInput(editor)) {
    ....
} if (isResourceDiffEditorInput(editor)) {
    ....
} else if (isResourceEditorInput(editor)) {
    resources.add(editor.resource);
}

The PVS-Studio warning: V7030 [CWE-670] Suspicious code formatting. The 'else' keyword is probably missing. editorService.ts 739

Above is a shortened snippet, with the original formatting kept intact. Judging by the formatting and the pattern of checks, that second block should be an else if, just like the last one.

We looked closely at this snippet and didn't find anything worse than an extra check running when the first condition is met. But code like this:

is misleading;
runs an unnecessary check;
and if the final statement were a plain else instead of else if, it would run even after the first if had already executed.

That last point is the scary one, and it's a good thing this particular block uses else if. Just like before, this is the kind of thing a human reviewer can easily miss, but a static analyzer catches it without any trouble.

When static analysis prepares the ground for refactoring

Besides catching potential errors, as we covered above, a static analyzer can also be a real asset for refactoring. A high number of warnings in one area can be a sign that certain code could, and sometimes should, be simplified. That's what we'll look at next.

Simplify switch-case

function walkChildren(
    node: TSESTree.Node, 
    visit: (child: TSESTree.Node) => void
) {
  switch (node.type) {
    ....
    case 'ForInStatement':  // <=
        visit(node.left);
        visit(node.right);
        visit(node.body);
        break;
    case 'ForOfStatement':
        visit(node.left);
        visit(node.right);
        visit(node.body);
        break;
    case 'WhileStatement':
    case 'DoWhileStatement':
        visit(node.test);
        visit(node.body);
        break;
    ....
    default:
        break;
  }
}

The PVS-Studio warning: V7008 [CWE-691] Two or more case branches perform the same actions. code-no-accessor-after-await.ts 365

In this snippet, the case branches for ForInStatement and ForOfStatement do exactly the same thing. Given that WhileStatement and DoWhileStatement are already stacked just below, there's a good argument for doing the same here.

Some occasional self-subtraction

....
while (byteCount > 0) {
  const chunk = this._chunks[chunkIndex];
  if (chunk.byteLength > byteCount) {
    // this chunk will survive
    const chunkPart = chunk.slice(0, byteCount);
    result.set(chunkPart, resultOffset);
    resultOffset += byteCount;
    if (advance) {
      this._chunks[chunkIndex] = chunk.slice(byteCount);
      this._totalLength -= byteCount;
    }

    byteCount -= byteCount;  // <=
  } else {
    // this chunk will be entirely read
    ....
    byteCount -= chunk.byteLength;
  }
}
return result;
....

The PVS-Studio warning: V7014 The identical expression 'byteCount' to the left and to the right of a compound assignment. ipc.net.ts 243

This one made it into the refactoring section because it's very likely the developers actually meant to zero out byteCount here, to guarantee the loop would exit. Figuring that out took a moment, though, since the else branch just below makes it look like this could just as easily be a typo.

To make the intent clear, it's better to just set the value to 0 directly.

Simplify the condition:

set(element: TextEditElement) {
  this._localDisposables.clear();

  this._localDisposables.add(
    dom.addDisposableListener(this._checkbox, 'change', e => {
    element.setChecked(this._checkbox.checked);
    e.preventDefault();
  }));
  if (element.parent.isChecked()) {
    this._checkbox.checked = element.isChecked();
    this._checkbox.disabled = element.isDisabled();
  } else {
    this._checkbox.checked = element.isChecked();
    this._checkbox.disabled = element.isDisabled();
  }
  ....
}

The PVS-Studio warning: V7004 [CWE-691] The 'then' statement is equivalent to the 'else' statement. bulkEditTree.ts 595

As things stand, the else block in this snippet doesn't do anything meaningful.

But like all the other snippets here, this one is best left for VS Code's active contributors and maintainers to look into.

Before we go

And that brings us to the end of the article. We've walked you through what we think are the most interesting things the PVS-Studio analyzer found in the VS Code source code. That's a solid outcome for us: even though the JavaScript and TypeScript analyzer is only just launching as an MVP, it's already catching suspicious code and real errors, even if a lot of them are simple typos for now. Down the line, once we add data-flow analysis and other features, the analyzer will get better at spotting more complex issues too.

By the way, some of our diagnostic rules started out as ideas our users and blog readers suggested to us. So if you've got thoughts on what kinds of errors our analyzer should be catching in JavaScript and TypeScript code, we'd love to hear them, some might even become real rules.

It was a lot of fun writing this article for you, and we hope you enjoyed reading it. Good luck out there, and see you next time.

P.S. You can try our analyzer on your own project here.

PVS-Studio 8.00: analyzers for JavaScript, TypeScript, and Go, plugins for WebStorm and GoLand, and more

Unicorn Developer — Fri, 28 Aug 2026 13:11:22 +0000

PVS-Studio 8.00 has been released. This version features new analyzers for JavaScript, TypeScript and Go projects, new IDE plugins for WebStorm and GoLand, expanded support for MISRA C++ 2023, and much more.

New analyzers and IDE plugins

The major PVS-Studio 8 release introduces new analyzers for JavaScript, TypeScript, and Go.

This version provides the analyzers with a basic set of diagnostic rules, a CLI for each analyzer, and plugins for the IDEs (WebStorm and GoLand).

The PVS-Studio plugin for Visual Studio Code has also major changes. It now supports the new analyzers and allows you to configure each analyzer from the options panel.

pvs-settings.toml configuration files

A new TOML-based configuration file format is now used to configure the new analyzers, the new IDE plugins, and the updated Visual Studio Code extension.

During its development, we aimed to cover all possible scenarios to provide the most user-friendly experience.

See more about new configuration files in the documentation.

MISRA C++ 2023

We continue to enhance the support of the MISRA C++ 2023 standard.

We've adapted sixteen existing diagnostic rules of the MISRA group to the MISRA C++ 2023 standard.

Additional information on MISRA support is available in the documentation.

Compiler support

In the release, we have also expanded the list of C and C++ compilers that are compatible with the PVS-Studio analyzer for these languages.

On Linux, the pvs-studio-analyzer utility supports the x86_64-pc-linux-gnu-c++ compiler.

The TI C2000-CGT compiler is also supported on all platforms via compilation monitoring and tracing.

Plugin for Qt Creator 20

The PVS-Studio plugin now supports Qt Creator 20.x. Now you can run analysis, view warnings, and work with code directly in the development environment.

The plugin for Qt Creator 14.x is no longer supported. We aim to maintain backward compatibility between the latest plugin versions and all Qt Creator versions released over the past two years.

See more about the plugin in the documentation.

Extended logging system for MSBuild projects

We continue to implement a new logging system, which will make it easier for us to detect issues that arise when running PVS-Studio analyzers.

Previously, we added extended logging to the cross-platform analyzer for C and C++ projects, but now it's also available for analyzer of C++ and C# projects based on MSBuild.

You can read more about the new logging system in the documentation.

Breaking changes

These changes are not backward compatible with earlier versions of the analyzer. You may need to alter the way how you use the analyzer due to these changes.

For Unreal Engine projects, the //V_USE_OLD_PARSER flag in the .pvsconfig file is now ignored. The new C++ parser has advanced enough to be recommended as the default for all analyzed projects. It now applies by default to projects using older Unreal Engine versions as well, regardless of whether the engine source code still contains the //V_USE_OLD_PARSER flag.
The Java analyzer now sorts the contents of suppress files. The update does not affect analysis results, but it may cause substantial changes to suppress files stored under version control the next time they are updated.
The messages issued for diagnostic rules V2558 and V547 have been updated for specific cases. Warnings that were previously suppressed may reappear in analysis reports.
Due to significant changes made to the Visual Studio Code extension to support the new PVS-Studio analyzers, the minimum supported Visual Studio Code version required to use the extension is being increased from 1.74 (November 2022) to 1.100 (April 2025).

New diagnostic rules

Java

V6136. Values of bit flags are duplicated.

JavaScript and TypeScript

V7001. Operands of a binary operator are equivalent.
V7002. The body of a function is fully equivalent to the body of another function.
V7003. A condition is equivalent to a condition in an 'else if' statement, making it unreachable.
V7004. The 'then' statement is equivalent to the 'else' statement.
V7005. A variable is assigned to itself.
V7006. An exception is created but never used. The 'throw' keyword may be missing.
V7007. The '|' and '&' operators bypass short-circuit evaluation. The right-hand operand will be evaluated even when the left operand is false.
V7008. Two or more 'case' branches perform the same actions.
V7009. A parameter is not used in a function, constructor, or method.
V7010. The return value of the function is required to be utilized.
V7011. Comparison with 'NaN' is incorrect. Use 'isNaN()' or 'Number.isNaN()' method instead.
V7012. The conditional expression always returns the same value.
V7013. Suspicious assignment in the condition. A comparison may have been intended.
V7014. An identical expression to the left and to the right of a compound assignment.
V7015. Suspicious formatting of assignment and unary operators.
V7016. Suspicious access to a collection element by a constant index inside a loop.
V7017. A loop counter is not used for collection indexing in the inner loop.
V7018. The expression 'A || (A && B)' is redundant and always evaluates to 'A'.
V7019. A variable is used as a counter for both inner and outer loops.
V7020. Suspicious code formatting. Curly brackets may be missing.
V7021. The postfix increment or decrement has no effect because the variable is overwritten.
V7022. It is possible that this 'else' branch should belong to the previous 'if' statement.
V7023. Suspicious use of a variable in similar code fragments. This may be a typo, and a different variable was intended.
V7024. Suspicious sub-expression in sequence of similar comparisons.
V7025. It is possible that an assigned variable should be checked in the following condition. Consider checking for a typo.
V7026. A stray semicolon after the condition of an if, for or while statement.
V7027. An object is passed as an argument to its own method.
V7028. A user-defined mathematical constant is used instead of a built-in constant. The resulting value may be inaccurate.
V7029. The line may have been commented out improperly, resulting in altered control flow.
V7030. Suspicious code formatting. The 'else' keyword may be missing.
V7031. A suspicious label was found inside a 'switch' statement. This may be a typo, and a different label was intended.
V7032. The loop counter is compared to its own initial value.
V7033. Suspicious similar comparisons. A typo may be present inside the expression.
V7034. The method in the child class does not override or implement the method of the ancestor class. A typo may be present in the name of the child class method.
V7035. Suspicious property implementation. Another field should probably be returned or assigned instead.
V7036. Suspicious precise comparison. Consider using a comparison with defined precision.
V7037. The nested loop counter is initialized with the outer loop counter.
V7038. The loop condition may be incorrect. The condition and update expression of the loop use different variables.
V7039. Unreachable code detected. Control flow never reaches this statement.
V7040. Infinite recursion detected.
V5801. OWASP. Code contains invisible characters that may alter its logic. Consider enabling the display of invisible characters in the code editor.

Go

V8001. Identical sub-expressions to the left and to the right of the 'foo' operator.
V8002. A variable is assigned to itself.
V8003. Consider inspecting the expression. Probably one of the operators should be used here: '-=', '+=' or '!='.
V8004. The use of 'if A {...} else if A {...}' pattern was detected. A potential logical error is present.
V8005. The 'then' statement is equivalent to the 'else' statement.
V8006. Unconditional 'break/continue/return/goto' within a loop.
V8007. Calling the 'recover' function inside the anonymous function that is not deferred will not recover execution from panic.
V8008. Suspicious access to a collection element by a constant index inside a loop.
V8009. Two or more 'case' branches perform the same actions.
V8010. Two or more 'case' branches have equivalent expressions.
V8011. An identical expression to the left and to the right of a compound assignment.
V8012. A function always returns the same value. Consider inspecting the program logic.
V8013. Incorrect format. A different number of format items is expected.
V8014. Two 'if' statements have identical conditions. The first 'if' statement contains function return, making the second 'if' redundant, or the code contains a logical error.
V8015. Suspicious use of the bitwise XOR operator '^'. The exponentiation operation may have been intended here.
V8016. The loop may be executed incorrectly or its condition will never be met. Inspect initial and final values in the 'for' loop.
V8017. The conditions of two adjacent 'if' statements are equivalent.
V8018. Comparison with 'math.NaN()' is meaningless. Use the 'math.IsNaN()' function instead.
V8019. Two or more equivalent expressions are specified inside the case expression list.
V8020. Recurring check. This condition was already verified on a previous line.
V8021. Using a unary operator several times is meaningless or reverses the result.
V8022. A parameter is not used in a function or method.
V8023. It is possible that a wrong variable of the 'error' type is checked for 'nil'.
V8024. Redundant type assertion. The type of a variable already embeds the type that is checked using type assertion.
V8025. The case in a type switch is unreachable. A previous case already covers this type.
V8026. The counter is not used inside the body of the nested loop.
V8027. Suspicious sub-expression in sequence of similar comparisons.
V8028. The outer loop counter is modified in the post statement of the inner loop. Perhaps the inner loop counter should be modified instead.
V8029. The outer loop counter is used in the condition of the inner loop. Perhaps the inner loop counter should be used instead.
V8030. The outer loop counter is used in the init statement of the inner loop. Perhaps a different variable should be used as a counter instead.
V8031. Using the call of the 'len' function as an index will result in an off-by-one error.
V8032. The return value of the function is required to be used.
V8033. Two similar code fragments were found. A second fragment may contain a typo.
V8034. Potentially incorrect order of arguments passed to a function.
V8035. Type assertion is always false. Check interfaces used in type assertion, as they contain methods with incompatible signatures.
V8036. A meaningless comparison with a variable of an unsigned type.
V8037. The same argument was passed to a function multiple times. A different argument may have been intended.
V8038. Parameter is always rewritten in the function body before being used.
V8039. Suspicious leading or trailing whitespace in the value used to identify an element.
V8040. The value of the variable is overwritten before it is used.
V5901. OWASP. Code contains invisible characters that may alter its logic. Consider enabling the display of invisible characters in the code editor.

Articles

Now it's time for some useful content: articles from our blog! Over the past two months, we've checked the OrcaSlicer projects, searched for bugs in BotSharp, tested the quality of Quarkus, discussed the new features of ES2026, recapped the JavaScript history, looked at subtle bugs in Go, and that's not all! You can see more in the list below.

C and C++

Csharp

Inside BotSharp: Finding bugs in the .NET AI platform's code

Java

Inside cloud-native Java: Exploring Quarkus

JavaScript and TypeScript

Go

One mistake no one has ever made. Right?

GameDev

Webinars

Let's make a programming language. AST

We're continuing our webinar series on building your own programming language in C++!

In the previous webinar, we created a parser that analyzes code and outputs parsing results to the console. Now it's time for the next important step building an AST (Abstract Syntax Tree).

In this video, we'll explain how ASTs work, build one step by step, and create a printer to visualize and inspect parsed code. This session will lay the groundwork for everything that comes next in our language implementation journey — semantic analysis, evaluation, and beyond.

Want to see more webinars? Check out upcoming events on the webinar page.

Conclusion

If you would like to receive news about PVS-Studio releases, subscribe to our newsletter here.

If you haven't checked your project with PVS-Studio yet, start with a trial license.

Tonight, ShadPS4 joins the hunt: uncovering bugs in the most popular PS4 emulator

Unicorn Developer — Wed, 26 Aug 2026 11:37:50 +0000

August 20 marked the 136th anniversary of Howard Phillips Lovecraft's birth, the man who created his own genre, Lovecraftian horror. Plenty of people have tried to copy or build on his ideas. Only a few have actually pulled it off.

Bloodborne is a good example. Its world draws on Lovecraft's work but stands on its own. For years, gamers could only dream of playing it on PC. Now that's finally possible, thanks to today's hero, the ShadPS4 emulator.

Welcome to the PC, good hunter. What bugs in ShadPS4 do you desire to hunt?

We checked ShadPS4's own code only, with no third-party libraries involved. The analysis was run on commit 24e68ba from the main branch. The findings in this article come from the High and Medium severity levels of the General Analysis group. The comments starting with //! are the author's.

The commit links are there to make it easier to verify the findings and fix the issues. They're not meant to discredit or criticize the people who wrote the code. I'm a big fan of both Lovecraft and Miyazaki's games, so a personal thank-you to everyone who contributes to the project.

Unlike my previous LLVM analysis, there won't be any weird merge artifacts here, such as two implementations getting mixed together. A hunter is never alone, and yet there are so few of them. May the hunt begin. Oh, I can't wait... hee hee...

Results of the check

Snippet 1. Fear your blindness

The PVS-Studio warning: V557 Array overrun is possible. The 3 index is pointing beyond array bound. input_handler.h 397

class InputBinding {
public:
  InputID keys[3];
  InputBinding(....) {
    ....
    if (k1 <= k2 && k1 <= k3) {
      ....
    } else if (k2 <= k1 && k2 <= k3) {
      ....
    } else {
      keys[0] = k3;
      if (k1 <= k2) {
        keys[1] = k1;
        keys[2] = k2;
      } else {
        keys[1] = k2;
        keys[3] = k1;
      }
    }
  }
}

A textbook buffer overflow. The entire file was added in a massive commit packed with all kinds of new features, so it's easy to see how this could have slipped through.

As it turned out, while this article was being written, the bug was found and fixed by changing keys[3] = k1 to keys[2] = k1. Still, it had managed to survive in the project for a year and a half.

Snippet 2. No mercy for "Liar"

The PVS-Studio warning: V547 Expression m_streams.size() >= 0 is always true. Unsigned type value is always >= 0. avplayer_source.cpp 132

class AvPlayerSource{
  ....
  std::vector<Stream> m_streams;
}

bool AvPlayerSource::FindStreams() {
  ....
  return m_streams.size() >= 0;
}

Let's see if there's actually a bug here. First of all, m_streams has always been a vector, so its size has always been unsigned.

The code was changed in this commit: the AvPlayerSource::FindStreams function replaced AvPlayerSource::HasStreams, and also took over some code from AvPlayerSource::Init.

bool AvPlayerSource::HasStreams() {
  return m_streams.size() >= 0;
}

If we dig even deeper, AvPlayerSource::HasStreams also had a predecessor:

bool AvPlayerSource::FindStreamInfo() {
  if (m_avformat_context == nullptr) {
    LOG_ERROR(Lib_AvPlayer, "Could not find stream info. NULL context.");
    return false;
  }
  if (m_avformat_context->nb_streams > 0) {
    return true;

  }
  return avformat_find_stream_info(m_avformat_context.get(), nullptr) == 0;
}

m_avformat_context is a smart pointer to the AVFormatContext type, and the nb_streams field is declared as follows:

unsigned int nb_streams;

As we can see, things were a little less tautological back then.

If we look for where AvPlayerSource::FindStreams is used, we find it only in AvPlayerState::ProcessEvent:

void AvPlayerState::ProcessEvent() {
  ....
  case AvEventType::AddSource: {
    std::shared_lock lock(m_source_mutex);
    if (m_up_source->FindStreams()) { //! Previously HasStreams(), 
                                      //! And before FindStreamInfo()
      SetState(AvState::Ready);
      OnPlaybackStateChanged(AvState::Ready);
    } else {
      OnWarning(ORBIS_AVPLAYER_ERROR_NOT_SUPPORTED);
      SetState(AvState::Error);
    }
    break;
  }
  ....
}

So, everything points to a simple typo. The developer most likely used >= instead of > when creating AvPlayerSource::HasStreams, and then copied the same condition into the AvPlayerSource::FindStreams.

Snippet 3. Let us cleanse these foul streets

The PVS-Studio warnings:

V568 It's odd that the argument of sizeof() operator is the sizeof (int) * 512 expression. aio.cpp 318

V1086 A call of the memset function will lead to underflow of the buffer id_state. aio.cpp 318

namespace Libraries::Kernel {
#define MAX_QUEUE 512
static s32* id_state;
static s32 id_index;
....
}

void RegisterAio(Core::Loader::SymbolsResolver* sym) {
  id_index = 1;
  id_state = (int*)malloc(sizeof(int) * MAX_QUEUE);
  memset(id_state, 0, sizeof(sizeof(int) * MAX_QUEUE));
  ....
}

The entire file was added in a single commit.

The expression sizeof(int) * 512 has type size_t, so sizeof(sizeof(int) * MAX_QUEUE)) is the size of size_t. Since size_t is usually 4 or 8 bytes, only part of the array will actually be zeroed out.

It's pretty safe to assume that the outer sizeof was added by mistake and that the intention was to zero out the entire buffer. It's hard to say for sure, though, because the array elements are only read by the sceKernelAio*** family of functions, where they're stored and called as pointers.

Hopefully, the hunters out there will take a closer look and either clean this whole thing up or leave a clear explanation of why it's actually needed.

Snippet 4. Beware of "Attack from behind"

The PVS-Studio warning: V595 The chunkIds pointer was utilized before it was verified against nullptr. Check lines: 173, 179.

s32 PS4_SYSV_ABI scePlayGoGetProgress(...., 
                  const OrbisPlayGoChunkId* chunkIds, ....)
{
  LOG_DEBUG(Lib_PlayGo, "called handle = {}, chunkIds = {},
            numberOfEntries = {}", handle,
           *chunkIds, numberOfEntries);
  if (handle != PlaygoHandle) {
    return ORBIS_PLAYGO_ERROR_BAD_HANDLE;
  }
  if (chunkIds == nullptr || outProgress == nullptr) {
    return ORBIS_PLAYGO_ERROR_BAD_POINTER;
  }
  ....
}

The LOG_DEBUG macro is defined in the log.h file. After the macro is expanded, the code looks like this:

do {
  if (auto logger = Common::Log::ALL_LOGGERS[Common::Log::Class::Lib_PlayGo]){
    logger->log(
      spdlog::level::debug,
      "[{}] <{}> ({}) {}:{} {}: "
      "called handle = {}, chunkIds = {}, numberOfEntries = {}",
      Common::Log::Class::Lib_PlayGo, 
      Common::Log::to_string_view(spdlog::level::debug),
      Common::GetCurrentThreadName(),
      spdlog::source_loc::basename(
      "path to playgo.cpp"),
      174, std::string_view(__func__) == "operator()" ? "lambda" : __func__,
      handle,
      *chunkIds, numberOfEntries);
  }
} while (false);

As we can see, when chunkIds == nullptr, we get a classic undefined behavior. The only thing that could save us here is having no logger for Common::Log::Class::Lib_PlayGo at that point. Unfortunately, all loggers are created in the main function at startup and remain active for the rest of the application's lifetime.

Even though this is only debug logging, the call to logger::log, and therefore the potential undefined behavior, still happens in a release build. The unnecessary log messages are filtered out inside the logger.

The macro has been there all along, with some variations in its form but with the dereference present in every version. The code that follows it was added later.

Judging by the commit message, the developer was expanding PlayGo support, the system that lets you start hunting before the whole game has finished downloading. The function was no longer just a placeholder and now had the necessary checks. The unconditional dereference of chunkIds however, seems to have slipped through.

There are several obvious ways to fix this, depending on the logging style used in the project. One option would be:


LOG_DEBUG(Lib_PlayGo, "called handle = {}, chunkIds = {}, 
                       numberOfEntries = {}", handle, 
                       chunkIds ? *chunkIds : static_cast<32>(-1), 
                       numberOfEntries);

Snippet 5. Oh, Yourself, please, carry on in my stead

The PVS-Studio warning: V570 The same value is assigned twice to the inComment variable. text_editor.cpp 2109

void TextEditor::ColorizeInternal() 
{
  ....
  if (mCheckComments) {
  ....
    while (currentLine < endLine || currentIndex < endIndex) {
      .... 
     //!~50 dense lines of code in which
     //!commentStartLine and commentStartIndex may change
      .... 
      bool inComment =
          (commentStartLine < currentLine ||
          (commentStartLine == currentLine && 
              commentStartIndex <= currentIndex));
       .....
         inComment = inComment =
            (commentStartLine < currentLine || 
            (commentStartLine == currentLine && 
               commentStartIndex <= currentIndex));
       ....
    }
  }
}

The entire thing was added in a single, massive commit.

Obviously, assigning inComment to itself makes no sense here. But how did it get there?

My guess is that the author wrote the inComment declaration, then copied the whole thing, initializer and all, from the line above and pasted it below without noticing the mistake.

Another possibility is that = was supposed to be == or !=, although neither really fits the logic of the algorithm. Of course, the final word here belongs to the developer or one of their fellow hunters.

Snippet 6. Treat "The unseen" with care

The PVS-Studio warning: V634 The priority of the * operation is higher than that of the << operation. It's possible that parentheses should be used in the expression. liverpool_to_vk.cpp 759

// Table 8.13 Data and Image Formats 
//[Sea Islands Series Instruction Set Architecture]
//All values are under 64
static const size_t amd_gpu_data_format_bit_size = 6;
//All values are under 16
static const size_t amd_gpu_number_format_bit_size = 4;

static auto surface_format_table = []() constexpr {
  std::array<vk::Format, 
      1 << amd_gpu_data_format_bit_size * 1 << amd_gpu_number_format_bit_size>
    result;
  for (auto& entry : result) {
    entry = vk::Format::eUndefined;
  }
  for (const auto& supported_format : SurfaceFormats()) {
    result[GetSurfaceFormatTableIndex(supported_format.data_format,
                                      supported_format.number_format)] =
        supported_format.vk_format;
  }
  return result;
}();

The line

1 << amd_gpu_data_format_bit_size * 1 << amd_gpu_number_format_bit_size

is equivalent to

1 << 6 * 1 << 4

Because of operator precedence, this is interpreted as

(1 << (6 * 1)) << 4

which gives us 1024.

According to GetSurfaceFormatTableIndex function, the maximum index in result is expected to be just under 1024:

static size_t GetSurfaceFormatTableIndex(AmdGpu::DataFormat data_format,
                                       AmdGpu::NumberFormat num_format) {
  DEBUG_ASSERT(u32(data_format) < 1 << amd_gpu_data_format_bit_size);
  DEBUG_ASSERT(u32(num_format) < 1 << amd_gpu_number_format_bit_size);
  size_t result = static_cast<size_t>(num_format) |
                (static_cast<size_t>(data_format) << 
                 amd_gpu_number_format_bit_size);
  return result;
}

This is consistent with the AMD documentation mentioned in the comment: 64 data formats and 14 ways for shaders to interpret them.

But the * 1 is puzzling. It looks like the intended expression might have been:

(1 << amd_gpu_data_format_bit_size) * ( 1 << amd_gpu_number_format_bit_size)

That also gives 1024. So, the operator precedence may have been overlooked, but the expression still happens to produce the correct result.

All the functions and constants were added in a single commit, so we can rule out any coordination issues.

In the end, this doesn't seem to be a bug. Still, the code is easy to misread, and some unsuspecting developer may one day fall prey to the horrors of operator precedence.

Snippet 7. "Strong foe" waits ahead but "don't give up"

The PVS-Studio warning: V579 The ZydisDecoderDecodeFull function receives the pointer and its size as arguments. It is possibly a mistake. Inspect the third argument. decoder.cpp 29

Previously, the file was named Disassembler.cpp:

void DecoderImpl::printInstruction(void* code, u64 address) {
  ZydisDecodedInstruction instruction;
  ZydisDecodedOperand operands[ZYDIS_MAX_OPERAND_COUNT_VISIBLE];
  ZyanStatus status =
    ZydisDecoderDecodeFull(&m_decoder, code, sizeof(code), 
                           &instruction, operands);
  if (!ZYAN_SUCCESS(status)) {
    fmt::print("decode instruction failed at {}\n", fmt::ptr(code));
  } else {
    printInst(instruction, operands, address);
  }
}

The ZydisDecoderDecodeFull function has an explanatory comment:

/**
 * @param buffer  A pointer to the input buffer.
 * @param length  The length of the input buffer. 
 *                Note that this can be bigger than the
 *                actual size of the instruction -- you don`t have to know
 *                the size up front. This length is merely used to prevent
 *                 Zydis from doing out-of-bounds reads on your buffer.
**/

Passing a pointer to some buffer along with the size of the pointer as the buffer length looks rather suspicious.

The length parameter takes quite a winding path through the code, but eventually ends up in a structure field:

  state.buffer_len = length;

That field is then used to limit instruction parsing, for example:

static ZyanStatus ZydisInputPeek(ZydisDecoderState* state,
    ZydisDecodedInstruction* instruction, ZyanU8* value)
{
  ....
  if (state->buffer_len > 0)
  {
      *value = state->buffer[0];
      return ZYAN_STATUS_SUCCESS;
  }
  return ZYDIS_STATUS_NO_MORE_DATA;
}

static ZyanStatus ZydisInputNext(ZydisDecoderState* state,
    ZydisDecodedInstruction* instruction, ZyanU8* value)
{
  ....
  if (state->buffer_len > 0)
  {
    *value = state->buffer++[0];
    ++instruction->length;
    --state->buffer_len;
    return ZYAN_STATUS_SUCCESS;
  }
  return ZYDIS_STATUS_NO_MORE_DATA;
}

Previously, a constant was used instead of sizeof(code):

#define ZYDIS_MAX_INSTRUCTION_LENGTH    15

That is the maximum instruction length in bytes on x86.

For the current code to be correct, there would have to be some guarantee that no instruction can be longer than the size of a pointer. I couldn't find one.

There is also some indirect evidence that this is a mistake in an example from the Zydis project, the disassembly framework used by the emulator:

ZyanU8 data[] = 
  { 
     0x51, 0x8D, 0x45, 0xFF, 0x50, 0xFF, 0x75, 0x0C, 0xFF, 0x75, 
     0x08, 0xFF, 0x15, 0xA0, 0xA5, 0x48, 0x76, 0x85, 0xC0, 0x0F, 
     0x88, 0xFC, 0xDA, 0x02, 0x00 
  }; 

 // The runtime address (instruction pointer) was chosen
 // arbitrarily here in order to better
 // visualize relative addressing. In your actual program,
 // set this to e.g. the memory address 
 // that the code being disassembled was read from.
 ZyanU64 runtime_address = 0x007FFFFFFF400000;

 // Loop over the instructions in our buffer.
 ZyanUSize offset = 0; 
 ZydisDisassembledInstruction instruction;
 while (ZYAN_SUCCESS(ZydisDisassembleIntel(
     /* machine_mode:    */ ZYDIS_MACHINE_MODE_LONG_64,
     /* runtime_address: */ runtime_address,
     /* buffer:          */ data + offset,
     /* length:          */ sizeof(data) - offset,
     /* instruction:     */ &instruction
 ))) { 
     printf("%016" PRIX64 "  %s\n", runtime_address, instruction.text);
     offset += instruction.info.length; 
     runtime_address += instruction.info.length; 
 } 

output:

007FFFFFFF400000   push rcx
007FFFFFFF400001   lea eax, [rbp-0x01]
007FFFFFFF400004   push rax
007FFFFFFF400005   push qword ptr [rbp+0x0C]
007FFFFFFF400008   push qword ptr [rbp+0x08]
007FFFFFFF40000B   call [0x008000007588A5B1]
007FFFFFFF400011   test eax, eax
007FFFFFFF400013   js 0x007FFFFFFF42DB15

Here, sizeof is used is used too, but this time on an array whose bounds are known at compile time, so it correctly gives the size of the buffer in bytes.

There is also almost identical code in the emulator's history. It was removed in 2023:

void Linker::LoadModuleToMemory(Module* m){
  ....
  auto* rt1 = reinterpret_cast<uint8_t*>
                      (m->elf.GetElfEntry() + m->base_virtual_addr);
  ZyanU64 runtime_address = m->elf.GetElfEntry() + m->base_virtual_addr;

  // Loop over the instructions in our buffer.
  ZyanUSize offset = 0;
  ZydisDisassembledInstruction instruction;
  while (ZYAN_SUCCESS(ZydisDisassembleIntel(
    /* machine_mode:    */ ZYDIS_MACHINE_MODE_LONG_64,
    /* runtime_address: */ runtime_address,
    /* buffer:          */ rt1 + offset,
    /* length:          */ sizeof(rt1) - offset,
    /* instruction:     */ &instruction
  ))) {
    fmt::print("{:#x}" PRIX64 "  {}\n", runtime_address, instruction.text);
    offset += instruction.info.length;
    runtime_address += instruction.info.length;
  }
  ....
}

The first thing that stands out is the exact same sizeof(***) - offset pattern for length as in Zydis example. The pointer's size is also obtained in exactly the same way as in the current code. That makes the case for this being a real error even stronger.

There is more. Another, now-defunct PS4 emulator also used Zydis and called ZydisDecoderDecodeFull with an instruction length of 15:

  ZyanStatus status = 
      ZydisDecoderDecodeFull(&m_decoder, code,
                             ZYDIS_MAX_INSTRUCTION_LENGTH,
                             &instruction, operands, 
                             ZYDIS_MAX_OPERAND_COUNT_VISIBLE,
                             ZYDIS_DFLAG_VISIBLE_OPERANDS_ONLY);

Still, to say for certain, we'd need to hear from the project's experienced developers.

Snippet 8. Despicable "Metamorphosis" therefore fear "Moon"

The PVS-Studio warning: V610 Undefined behavior. Check the shift operator <<. The right operand ((64 - systemLang - 1) = [16..63]) is greater than or equal to the length in bits of the promoted left operand. playgo.cpp 233

int scePlayGoConvertLanguage(int systemLang) {
    if (systemLang >= 0 && systemLang < 48) {  //! systemLang: [0..47]
        return (1 << (64 - systemLang - 1));   //! 1 << [16..63]
    } else {
        return 0;
    }
}

The function was added in its entirety, along with the scePlayGoInitialize code below it.

Since the emulator is currently built for the x86-64 architecture, where int is 4 bytes, any systemLang value below 32 will cause an overflow and undefined behavior.

But does that actually happen? Let's trace where the systemLang parameter comes from.

Our function is called only from scePlayGoInitialize:

s32 PS4_SYSV_ABI scePlayGoInitialize(OrbisPlayGoInitParams* param) {
  ....
  s32 system_lang = 0;
  sceSystemServiceParamGetInt(OrbisSystemServiceParamId::Lang, &system_lang);
  playgo->langMask = scePlayGoConvertLanguage(system_lang);

  return ORBIS_OK;
}

And system_lang gets its value from sceSystemServiceParamGetInt:

s32 PS4_SYSV_ABI sceSystemServiceParamGetInt(
  OrbisSystemServiceParamId param_id,
  int* value
)
{
  // TODO this probably should be stored in config for UI configuration
  LOG_DEBUG(Lib_SystemService, "called param_id {}", u32(param_id));
  if (value == nullptr) {
    LOG_ERROR(Lib_SystemService, "value is null");
    return ORBIS_SYSTEM_SERVICE_ERROR_PARAMETER;
  }
  switch (param_id) {
  case OrbisSystemServiceParamId::Lang: {
    s32 lang = EmulatorSettings.GetConsoleLanguage();
    if (lang == 0x15 && g_sdk_version < Common::ElfInfo::FW_200) {
      lang = 0x12;
    }
    if (lang == 0x16 && g_sdk_version < Common::ElfInfo::FW_250) {
      lang = 2;
    }
    if ((lang >= 0x17 && lang <= 0x1a) && 
         g_sdk_version < Common::ElfInfo::FW_500) {
      lang = 0x12;
    }
    if ((lang >= 0x1b && lang <= 0x1d) && 
        g_sdk_version < Common::ElfInfo::FW_500) {
      lang = 1;
    }
    if (lang == 0x1e && g_sdk_version < Common::ElfInfo::FW_1000) {
      lang = 0x12;
    }
    *value = lang;
    break;
  }
  ....
  }
  return ORBIS_OK;
}

As we can see, small system_lang values are entirely possible. In fact, they are the ones we are most likely to get. According to the documentation, each supported language has a number from 0 to 47. Japanese, for example, is 0, English is 1, and Russian is 8. So, any game using Japanese, for example, is guaranteed to trigger the overflow.

The conditions mentioned above also make more sense now. For example, when the SDK version is old enough, standard French is used instead of Canadian French:


  if (lang == 0x16 && g_sdk_version < Common::ElfInfo::FW_250)
    lang = 2;

There's more evidence that this is a bug. The same function in another PlayGo implementation is virtually identical, but avoids the overflow:

static inline ScePlayGoLanguageMask scePlayGoConvertLanguage(int32_t systemLang)
{
  return (systemLang >= 0 && systemLang < 48) ? 
         (1ULL << (64 - systemLang - 1))      : 
         0ULL;
}

Snippet 9. Time for "Hidden path"

The PVS-Studio warning: V796 It is possible that break statement is missing in switch statement. hull_shader_transform.cpp 247

void WalkUsersOfTessConstantHelper(IR::Use use, u32 inc,bool propagateError){
  IR::Inst* inst = use.user;
  switch (use.user->GetOpcode()) {
  case IR::Opcode::LoadSharedU32:
  case IR::Opcode::LoadSharedU64:
  case IR::Opcode::WriteSharedU32:
  case IR::Opcode::WriteSharedU64: {
    bool is_addr_operand = use.operand == 0;
    if (is_addr_operand) {
      u32 counter = inst->Flags<u32>();
      inst->SetFlags<u32>(counter + inc);
      ASSERT_MSG(!propagateError, 
          "LDS instruction {} accesses ambiguous attribute type",
           fmt::ptr(use.user));
      // Stop here
      return;
    }
  }
  case IR::Opcode::Phi: {
    auto it = phi_infos.find(use.user);
    ....
  }
  ....
}

Earlier in this branch, there was an unconditional exit:

  switch (use.user->GetOpcode()) {
  case IR::Opcode::LoadSharedU32:
  case IR::Opcode::LoadSharedU64:
  case IR::Opcode::WriteSharedU32:
  case IR::Opcode::WriteSharedU64: {
    u32 counter = inst->Flags<u32>();
    inst->SetFlags<u32>(counter + inc);
    // Stop here
    return;
  }

The commit message says:

Ignore when a user contributes to the wrong operand of an LDS inst, for

example the data operand of WriteShared* instead of the address operand.

This can mistakenly happen due to phi nodes.

The commit says to ignore cases where a user contributes to the wrong operand. That means we shouldn't fall through when use.operand != 0, and a break is indeed missing here.

If that's not the case, a little hint like [[fallthrough]] would have helped guide those of us who weren't blessed with the same insight.

Snippet 10. Treat "Lever" with care or you must accept "Ignoring"

The PVS-Studio warning: V547 Expression compare < 0 is always false. Unsigned type value is never < 0. np_common.cpp 49

s32 PS4_SYSV_ABI sceNpCmpNpIdInOrder(OrbisNpId* np_id1, OrbisNpId* np_id2,
                                     u32* out_result) {
  ....
  // Compare data
  u32 compare =
    std::strncmp(np_id1->handle.data, np_id2->handle.data, 
                 ORBIS_NP_ONLINEID_MAX_LENGTH);
  if (compare < 0) {
    *out_result = -1;
      return ORBIS_OK;
  } else if (compare > 0) {
    *out_result = 1;
    return ORBIS_OK;
  }
  ....
}

Once again, the entire file was added in a single commit (it had previously lived in a different directory).

Let me briefly recap how strncmp works:

int strncmp( const char* lhs, const char* rhs, std::size_t count );

The sign of the result is the sign of the difference between the values of the first pair of characters (both interpreted as unsigned char) that differ in the arrays being compared.

It looks like the author simply got the type wrong, using an unsigned type where a signed one was intended.

With our co-op in one world wrapped up, let's take a quick look at another. Besides the main repository, the ShadPS4 project has a fairly popular fork specifically tailored to Bloodborne: diegolix29/shadPS4.

It has drifted a couple thousand commits away from upstream and, alongside the usual problems, has a few of its own.

Snippet 11. The sky and the cosmos are one

The PVS-Studio warning: V590 Consider inspecting the 'deltaTime <= 0.0f || deltaTime < 0.0001f' expression. The expression is excessive or contains a misprint. controller.cpp 201

void GameController::CalculateOrientation(/*....*/
                           float deltaTime,
                           Libraries::Pad::OrbisFQuaternion& lastOrientation,
                           Libraries::Pad::OrbisFQuaternion& orientation) {
  constexpr float MAX_DELTA_TIME = 0.1f;
  if (deltaTime > MAX_DELTA_TIME) {
    deltaTime = MAX_DELTA_TIME;
  }

  if (deltaTime <= 0.0f || deltaTime < 0.0001f) {
    orientation = lastOrientation;
    return;
  }
  ....
}

The MAX_DELTA_TIME block and the orientation assignment came in a separate commit.

At first glance, it looks like deltaTime < 0.0001f should actually be deltaTime > 0.0001f. This is indirectly supported by a similar snippet in the upstream repository:

  if (delta_time > 1.0f) {
    orientation = last_orientation;
    return;
  }

But then the MAX_DELTA_TIME block would make little sense. So I guess it's time to dig a little deeper into the lore of controller orientation calculations.

First, let's look at what delta_time actually is. Surprisingly, it's the time elapsed since the last update, for example:

const float delta_time = static_cast<float>
            (timestamp - m_last_orientation_update) / 1'000'000.f;

After looking into it, I realized that the upstream version with the 1.0f constant is there to guard against emulator slowdowns and pauses that could otherwise make things go haywire.

The fork takes a slightly different approach: in this case, it simply updates the orientation using a fixed delta of 0.1f. This means the questionable part is:

  if (deltaTime <= 0.0f || deltaTime < 0.0001f) {
    orientation = lastOrientation;
    return;
  }

It seems to serve a different purpose: a paranoid safeguard against invalid data, since both negative and extremely small deltas can result in incorrect values.

So, with a fair degree of confidence, we can say that the left side of the check deltaTime <= 0.0f is unnecessary.

Snippet 12. Time for "jump"

The PVS-Studio warning: V1082 Function marked as 'noreturn' may return control. This will result in undefined behavior. ir_emitter.cpp 15

[[noreturn]] void ThrowInvalidType(Type type,
             std::source_location loc = std::source_location::current()) {
  const std::string functionName = loc.function_name();
  const int lineNumber = loc.line();
  // UNREACHABLE_MSG("Invalid type = {}, functionName = {}, line = {}",
  //                  u32(type), functionName,
  //                  lineNumber);
}

The UNREACHABLE_MSG macro did indeed make the function noreturn:

#define UNREACHABLE_MSG(...)                                 \
  do {                                                       \
      LOG_CRITICAL(Debug, "Unreachable code!\n" __VA_ARGS__);\
      unreachable_impl();                                    \
  } while (0)

[[noreturn]] void unreachable_impl() {
  Common::Log::Stop();
  std::fflush(stdout);
  Crash();
  throw std::runtime_error("Unreachable code");
}

These lines were commented out in a commit with the message "SOTC hacks" (SOTC presumably stands for Shadow of the Colossus).

This change isn't present in the upstream version, so the analyzer had nothing to complain about there.

There's not much mystery here: the attribute was simply left behind. According to the C++ standard, this is undefined behavior, so [[noreturn]] should be removed.

Snippet 13. Treat hunter with care and don't be fooled

The PVS-Studio warning: V501 There are identical sub-expressions 'serial == "CUSA03014"' to the left and to the right of the '||' operator. storage_image_sync.cpp 42

void StorageImageSync::Sync(VideoCore::ImageId image_id) {
  const auto& serial = Common::ElfInfo::Instance().GameSerial();
  if (serial == "CUSA11227" || serial == "CUSA12982" || serial == "CUSA00093" ||
   serial == "CUSA03173" || serial == "CUSA00900" || serial == "CUSA00208" ||
   serial == "CUSA01363" || serial == "CUSA01322" || serial == "CUSA003027" ||
   serial == "CUSA00299" || serial == "CUSA00207" || serial == "CUSA03014" ||
   serial == "CUSA03023" || serial == "CUSA03014" || serial == "CUSA00900" ||
   serial == "CUSA00003" || serial == "CUSA01627" || serial == "CUSA01778" ||
   serial == "CUSA03388" || serial == "CUSA01589" || serial == "CUSA01760" ||
   serial == "CUSA07439" || serial == "CUSA07339" || serial == "CUSA08692" ||
   serial == "CUSA08495" || serial == "CUSA50617" || serial == "CUSA18723" ||
   serial == "CUSA28863" || serial == "CUSA00093" || serial == "CUSA00003") {
     return;
  }
  ....
}

As we can see, the comparison with CUSA03014 appears twice, and both copies were added in the same commit.

This file doesn't exist in the upstream repository at all, so there is no corresponding warning there.

It's somewhat fitting that a CUSA ID is a five-digit serial number assigned to PS4 games, while our duplicate, CUSA03014, belongs to Bloodborne: The Old Hunters Edition.

CUSA003027 also stands out visually: it's longer than all the other IDs, breaking up the neat sequence, and being six digits long, it doesn't make sense.

Whether those redundant comparisons can simply be removed, or some of the IDs should be replaced with others, is something only the developer can say.

Snippet 14. Remember key but fear Malformed thing

The PVS-Studio warning: V766 An item with the same key 'vk::Format::eR8G8B8A8Srgb' has already been added. host_compatibility.cpp 202

/**
 * @brief The format compatibility class according to the Vulkan specification
 * @url
 * https://registry.khronos.org/vulkan/specs/
.* 1.3-extensions/html/vkspec.html#formats-compatibility-classes
 * @url
 * https://github.com/KhronosGroup/VulkanValidationLayers/
 * blob/d37c676f/layers/generated/vk_format_utils.cpp#L70-L812
**/
static const std::unordered_map<vk::Format,CompatibilityClass> FORMAT_TABLE ={
    ....
    {vk::Format::eR64G64Uint, CompatibilityClass::_128BIT},
    {vk::Format::eR64Sfloat, CompatibilityClass::_64BIT},
    {vk::Format::eR64Sint, CompatibilityClass::_64BIT},
    {vk::Format::eR64Uint, CompatibilityClass::_64BIT},
    {vk::Format::eR8G8B8A8Sint, CompatibilityClass::_32BIT},
    {vk::Format::eR8G8B8A8Snorm, CompatibilityClass::_32BIT},
    {vk::Format::eR8G8B8A8Srgb, CompatibilityClass::_32BIT},   // <= 32BIT
    {vk::Format::eR8G8B8A8Sscaled, CompatibilityClass::_32BIT},
    {vk::Format::eR8G8B8A8Uint, CompatibilityClass::_32BIT},
    {vk::Format::eR8G8B8A8Unorm, CompatibilityClass::_32BIT},
    {vk::Format::eR8G8B8A8Uscaled, CompatibilityClass::_32BIT},
    ....
    {vk::Format::eR8G8Uscaled, CompatibilityClass::_16BIT},
    {vk::Format::eR8Sint, CompatibilityClass::_8BIT},
    {vk::Format::eR8Snorm, CompatibilityClass::_8BIT},
    {vk::Format::eR8Srgb, CompatibilityClass::_8BIT},
    {vk::Format::eR8G8B8A8Srgb, CompatibilityClass::_8BIT},    // <= 8BIT
    {vk::Format::eR8Sscaled, CompatibilityClass::_8BIT},
    {vk::Format::eR8Uint, CompatibilityClass::_8BIT},
    ....
};

The key eR8G8B8A8Srgb appears twice, with two different values: CompatibilityClass::_8BIT and CompatibilityClass::_32BIT. The C++ standard does not specify which entry will take precedence.

The link in the comment leads to the following entry:

  {VK_FORMAT_R8G8B8A8_SRGB,
       {FORMAT_COMPATIBILITY_CLASS::_32BIT, ....} }

In other words, the 8BIT value doesn't match the pattern and also seems unnecessary. There is no corresponding entry between VK_FORMAT_R8_SRGB and VK_FORMAT_R8_SSCALED values in the reference map. The same map is present upstream, but, unsurprisingly, it doesn't contain the second 8BIT option, which was added separately later in the fork.

Only the developers can say for certain which of the two entries should be kept.

Will the hunt ever end?

You will be freed... from this terrible hunter's dream.

Even with the power of C++ at their disposal, developers are still human. They can make mistakes, miss typos, and lose focus. Luckily, there are tools to help them survive the hunt, including those we craft in our Abandoned Old Workshop. One of them is PVS-Studio, which you can use for free on open-source projects.

Even if your project isn't open source, you can still try the analyzer for free. You know that, right?

As usual, we opened GitHub issues for what the check found: upstream, fork.

Farewell good hunter, may you find your worth in the waking world.

How to bring static analysis into your project: a practical guide for managers

Unicorn Developer — Mon, 24 Aug 2026 13:49:15 +0000

Static code analysis stopped being a tool just for developers a long time ago. For product managers, technical directors, and information security teams, it now forms part of the quality and security management system for development.

In this article, we'll walk through how to bring static analysis into your development process step by step, who's responsible for what at each step, and how to move from irregular analyzer runs to consistent, ongoing code quality control.

Step 1. Where to focus static analysis first

It all starts with determining what static analysis will actually cover. Two questions need answers: which products will be checked, and what languages those products are written in.

The Chief Technology Officer (CTO), product owners, and the information security team usually make this decision. Their choices determine where static analysis will have the greatest impact. They also identify which risks need to be addressed first. Then they assess whether the technologies already in use align with the languages and platforms the analyzer supports.

This stage results in a concrete list of projects slated for static analysis. It also produces an overview of the tech stacks involved.

This is also when many companies test several analyzers side by side. Our clients follow the same process. They choose PVS-Studio's SAST solution for its diagnostic accuracy, performance, and integration options. The development team also adapts the tool quickly to each customer's infrastructure.

PVS-Studio already covers C, C++, C#, and Java, and as of August 2026 it added analyzers for Go, JavaScript, and TypeScript as well. One tool can then cover several product teams at once, instead of the company relying on several specialized tools for each one.

Step 2. Where to plug static analysis into your pipeline

Static analysis can be integrated into the development process at different levels. The right choice depends on the team's maturity, quality requirements, and available resources.

Manual runs on developers' machines

This is usually the first step in implementing static analysis. Developers check their code as they write it and fix issues before committing changes to version control. This approach follows the idea of shift-left testing, which pushes testing as early as possible into the development lifecycle. Errors get caught the moment they appear, when fixing them takes the least time and effort. This keeps defects from carrying over into later stages of development, testing, and production, where fixing them costs far more.

Automatic runs in CI/CD

Bugs can still slip past a developer. Human error happens, and some products are simply harder to test. That's why the next line of defense is CI/CD-level analysis, where the product is built and checked automatically on a regular basis. This turns analysis into part of the standard build process and gives teams a way to track the health of the codebase. Defects get caught and fixed before changes move on to later stages of the lifecycle, which lowers the cost of fixing them and cuts the risk of bugs reaching production.

Automatic runs on merge requests

Checks at this stage catch issues right at the commit, in pull or merge requests. If your project follows a pull/merge request workflow, you can protect the repository by checking every contributor's changes automatically. A merge request only goes through, for instance, if the analyzer finds no critical errors.

Reporting into quality-control dashboards

Analysis results can flow into SonarQube, DefectDojo, or similar platforms. This gives teams a consistent view of quality and security metrics across all their software products.

This is usually the stage that makes or breaks an implementation. If a tool forces teams to change how they operate, they end up treating it as a roadblock. PVS-Studio takes the opposite approach and fits into workflows as they already exist. Static analysis ends up as a natural part of development, not a separate control procedure.

Step 3. Which infrastructure to target

Once you've decided where static analysis plugs into your pipeline, the next step is figuring out the infrastructure that will run it.

Two groups of platforms usually come into play:

Developers' local workstations, where analysis is used to quickly verify changes.
Server environments, where analysis runs automatically as part of continuous integration and delivery.

The development team lead and developers decide which operating systems, build servers, and infrastructure the analyzer should run on, factoring in the tool's system requirements, licensing policy, and the specifics of the existing build pipeline.

PVS-Studio licensing policy. PVS-Studio is a tool for teams, not for a single user. Licenses come in packages tied to the number of people on the team. Here's how the licensing works.

The license is based on how many people use the analysis results, not how many machines run the tool.
One license can cover developers across multiple departments or projects.
The license comes with no limits on code volume, diagnostic rules, or new versions.
PVS-Studio analyzer developers handle support requests directly.

PVS-Studio offers two types of licenses:

Team — for small teams of up to 9 people. Includes the core functionality.
Enterprise — for large teams of 10 or more people. More features, more ways to use the tool, and higher-priority support.

Curious about pricing? Take a look at this page to find the license that fits your team.

Step 4. How static analysis can fit into your toolchain

Once you've identified target projects and platforms, the next step is exploring how the tool integrates into your existing development ecosystem.

This is usually where teams hit the limits of whatever tool they've chosen. PVS-Studio was designed to integrate smoothly into existing development environments. It supports most popular IDEs, build systems, CI/CD platforms, and quality management systems, so implementation typically doesn't require changing your existing processes.

IDE integration. To make static analysis easier to use, it's worth integrating it directly into the IDEs developers already use:

Regular analysis in CI/CD. For server-side analysis, check how the tool runs on the build systems you already use. In practice, this can include:

Checking projects using MSBuild from the command line (C, C++, C#)
Using the CMake module (C, C++)
Checking C and C++ projects regardless of build system (Windows, Linux)
Cross-platform analysis of C and C++ projects based on the JSON Compilation Database
Integrating PVS-Studio with Gradle and Maven (Java)
Using JavaScript and TypeScript analyzer from the command line
Using Go analyzer from the command line

The result is analysis that runs automatically without disrupting existing workflows.

Analysis on merge requests. To keep new defects out of the codebase, it's worth setting up analysis at the commit and pull/merge request stage. PVS-Studio can integrate with almost any system that supports merge request review. Ready-made integration scripts already exist for popular platforms like GitHub and GitLab. Command-line support and flexible automation also let the analyzer integrate with other source control systems and DevOps platforms used in your organization.

Integration with your quality-control dashboards. To track analysis results consistently across projects, it's worth using a software quality and security platform. This makes development quality measurable. Managers get consistent metrics across every project, can track compliance with internal requirements, and can quickly spot teams or products that need extra attention.

PVS-Studio integrates with platforms including:

Step 5. How to build a code quality control workflow

Once integration is fully configured, the next step is setting guidelines for how the team uses static analysis day to day.

Configuring the environment for analysis. Don't turn on every diagnostic rule at once. A better approach is to review the full list, pick the rules that matter most for your project, run a first scan, and see what comes back. From there, you fine-tune: filter out irrelevant warnings and build a rule set for everyday development.

PVS-Studio lets you configure this through .pvsconfig files, options for suppressing false positives, and user annotations for functions, classes, and variables. Annotations give the analyzer extra context about what the code is meant to do. That makes the diagnostic rules more precise, cuts down false positives, and improves analysis for projects using custom libraries, frameworks, or non-standard approaches.

Building a workflow for local checks. Developers run analysis locally and clear warnings before committing changes.

Extending checks into CI/CD. From there, analysis becomes part of continuous integration.

PVS-Studio supports the following CI/CD systems and tools:

We recommend running automatic analysis both on individual commits and as part of regular nightly builds.

Establishing control over commits and merge requests. For new changes, we recommend configuring static analysis to run automatically before branches merge. This helps prevent technical debt from piling up and keep code quality consistent.

Enforcing quality gates. To automate quality control, set up quality gates in your quality management platform.

Quality gates check the build against a set of predefined criteria before letting it move forward, for example:

No critical errors
No new warnings of high severity levels
Compliance with defined quality thresholds

Tracking quality metrics over time. As the tool stays in use, it builds up a growing dataset on software quality. Reviewing that data regularly makes it possible to spot erroneous patterns, track how technical debt is trending, and ground management decisions in data rather than intuition.

Step 6. How to approach your existing codebase

Analyzing existing code is one of the most critical stages of implementation.

In large projects, the first analyzer run can surface thousands of warnings, and resolving all of them takes significant development effort. Trying to fix everything at once usually overwhelms the team and undermines trust in the tool.

Assessing the scope of the problem. Run the analysis with your chosen configuration and get a total count of the issues detected.

Establishing a baseline. PVS-Studio's mechanism for suppressing warnings, known as baselining, covers two common scenarios:

PVS-Studio is being introduced to the project for the first time and generates a large number of warnings across the entire codebase. In this case, the team enables the analyzer only for new code and comes back to the existing warnings in a later pass.
PVS-Studio is used in the project on a regular basis. False positives that show up in the analyzer reports can be suppressed without touching the source code.

Baselining suppresses the analyzer's existing warnings so they no longer show up in future reports. It doesn't require any changes to the project's source files. That lets the team focus on catching new defects instead of having to fix every issue in the legacy code right away.

Planning fixes for critical issues. The next step is to develop a plan to address the most critical warnings that must be resolved before the tool can be put into full operation.

Reducing technical debt incrementally. Once static analysis is up and running, the team can steadily work down the backlog of existing issues, improving code quality and security without slowing down development.

Bottom line: static analysis needs to be part of the process, not a one-off check

Bringing PVS-Studio into your workflow isn't about installing a standalone tool. It's about building a full-fledged process for software quality and security. Static analysis delivers the most value when it's integrated into every stage of the development lifecycle, from a developer's own machine to centralized quality management systems.

Following these steps in order helps minimize implementation risk, keeps the transition to new development practices under control, and builds a solid mechanism for catching errors before they ever reach production.

PVS-Studio today is used by companies with very different development requirements: from game studios to network equipment providers, teams building real-time operating systems, and more. Despite the differences in their products and processes, they've all arrived at the same conclusion: static analysis is no longer a one-time check. It's become an ongoing mechanism for improving code quality, security, and the maturity of development practices.

If you'd like advice on introducing and configuring PVS-Studio for your team, join a product demo with our developers. In a technical walkthrough, we'll cover PVS-Studio's features and integrations, show the analyzer in action, go over sample results, and answer your team's questions. Demos typically run 30 to 60 minutes.

To try the analyzer yourself, get a free PVS-Studio trial license. See this link for details.

Bloated C++ code

Unicorn Developer — Wed, 19 Aug 2026 14:25:59 +0000

There's an old joke among programmers that you should never pay them by the line of code, because they'll end up writing long, pointless code and leaning hard on copy-paste. These days that joke writes itself, except now the "programmer" is GenAI, and it actually gets paid per line. Ironic.

One of my hobbies is picking apart generated C++ code, just to get a sense of how the software development industry is evolving: which problems are fading out, and which new ones are cropping up. After reading my post Real-world C++ projects built with GenAI: do they exist? someone suggested I check out the VibeTensor project, so I did.

VibeTensor: System Software for Deep Learning, Fully Generated by AI Agents

I checked it with the PVS-Studio static analyzer and also read through the C++ code with my own eyes. I was curious how many errors a classic code review versus static analysis would each turn up.

Turns out I still can't answer that. The code is bloated to the point of being unreadable, and that bloat is the whole problem. Wading through it felt like slogging through a swamp, and the analyzer got just as bogged down as I did.

Don't get your hopes up for a big error count either. There's barely any code in this project actually worth analyzing. And that's despite the project not being small at all, over 400 C++ files, around 100,000 lines total.

That size is deceptive though. Most of the project isn't really there to be looked at or analyzed. The core issue here is just verbosity. You see it in code snippets that repeat over and over, and in plain pointless busywork that bloats the code for no reason.

In the past, people would've called this copy-paste coding. That's not quite what happened here, but code generation gets you to the same place. Instead of extracting shared logic into functions, new code just gets generated again and again to solve nearly identical problems.

Scroll through the files for a while and you'll start getting déjà vu, as the same blocks of code keep popping up. They're sort of different, sort of not. Here's what I mean:

Like I mentioned in my article C++: Write, shorten, optimize, this exact block of code shows up nine times across different tests:

const std::size_t nd = sizes.size();
std::vector<int64_t> strides(nd, 0);
int64_t acc = 1;
for (std::ptrdiff_t i = static_cast<std::ptrdiff_t>(nd) - 1; i >= 0; --i) {
  strides[static_cast<std::size_t>(i)] = acc;
  const auto sz = sizes[static_cast<std::size_t>(i)];
  acc *= (sz == 0 ? 1 : sz);
}

int64_t ne = 1;
bool any_zero = false;
for (auto s : sizes) {
  if (s == 0) {
    any_zero = true;
    break;
  }
  ne *= s;
}
if (any_zero) {
  ne = 0;
}

But that's just the tip of it. PVS-Studio keeps spitting out warnings about redundant code, one after another. Sometimes it's the small stuff:


for (int i = 0; i < dl.ndim; ++i) {
  int64_t n = (dl.ndim == 0) ? 1 : dl.shape[i];
  int64_t d = n > 0 ? (n - 1) : 0;
  if (d == 0) continue;
  int64_t st = (dl.ndim == 0) ? 1 : strides[static_cast<std::size_t>(i)];

PVS-Studio issues the same warning twice: V547 Expression 'dl.ndim == 0' is always false. And it's right, if the loop runs at all, dl.ndim can't be zero at that point. The code simplifies down to:

for (int i = 0; i < dl.ndim; ++i) {
  int64_t d = std::max(0ll, dl.shape[i] - 1);
  if (d == 0) continue;
  int64_t st = strides[i];

In other spots, you can't call the bloat minor anymore. Right there, PVS-Studio fires off whole groups of warnings at once:

V547 [CWE-570] Expression 'is_empty' is always false. tensor_bindings.cc 3007
V547 [CWE-570] Expression 'print_size' is always false. tensor_bindings.cc 3015
V547 [CWE-571] Expression '!parts.empty()' is always true. tensor_bindings.cc 3023

The code that triggered these warnings seems fairly slick on the surface: an array here, a loop there... Take a closer look, though, and it's garbage.

bool is_empty = false; // handled above; always false here
bool print_size = is_empty && (self.sizes().size() != 1);
bool suppress_dtype_non_empty = (!is_empty) &&
  (self.dtype() == ScalarType::Float32 ||
   self.dtype() == ScalarType::Int64 ||
   self.dtype() == ScalarType::Bool);
bool print_dtype = !suppress_dtype_non_empty;
if (is_empty) {
  // For empty tensors, only print dtype when dtype != default float32
  print_dtype = (self.dtype() != ScalarType::Float32);
}

std::string out = "tensor(";
out += body;
std::vector<std::string> parts;
if (print_size) {
  parts.push_back(std::string("size=") + format_sizes(self.sizes()));
}
if (print_dtype) {
  parts.push_back(std::string("dtype=") + dtype_name(self.dtype()));
}
// Always include device suffix for CUDA tensors
parts.push_back(std::string("device='cuda:") +
                std::to_string((int)self.device().index) + "'");
if (!parts.empty()) {
  out += ", ";
  for (std::size_t i = 0; i < parts.size(); ++i) {
    if (i) out += ", ";
    out += parts[i];
  }
}
out += ")";
return out;

At the very least, that manual loop for building the output string can be swapped out right away for:

return std::format("tensor({})", parts | std::views::join_with(", "sv));

If you take a closer look, you can actually cut all this bloated mess down to a third of its size:


std::string out = "tensor(" + body + ", ";

if (self.dtype() != ScalarType::Float32 &&
    self.dtype() != ScalarType::Int64 &&
    self.dtype() != ScalarType::Bool)
{
  out += std::string("dtype=") + dtype_name(self.dtype()) + ", ";
}
out += "device='cuda:" + std::to_string((int)self.device().index) + "')";
return out;

Here's the interesting part: look at the analyzer's output for the code as it stands, and it seems like there aren't any real errors. The code is complex, but it works correctly, no out-of-bounds array access. Credit where it's due, AI.

But once you look past the surface complexity to what the code is actually doing, you realize there's nowhere left for it to go wrong. It's all the same, just stretched out over more lines. Not much credit left after that.

Bottom line: there aren't really 100,000 lines of C++ code in this project. Move the duplicates into functions, refactor, and I'd guess the code shrinks by a factor of 5. A 20,000-line project isn't worth taking seriously. What you're looking at here isn't errors, just bloated code and analyzer warnings about a pile of always-true and always-false conditions.

Sure, the code is longer, so what? That's the thinking, anyway: it's not meant to be refactored by a person, if you need something different, you just generate a new version.

And if your goal is selling GenAI and you don't actually care what happens to the project down the line, fine, that logic holds. But if you actually need this thing to be maintained as a real project, the actual "cost per line of code" runs a lot higher than it looks.

A few things bloated code actually costs:

More lines of code mean a higher cost to generate them.
If another agent is the one reviewing your pull requests, you're paying that agent more too.
Bloated functions cost more to generate unit tests for.
Any AI-assisted code change costs more, since more lines have to be read in and written out.
More context means a higher chance of errors when making changes (you might miss a fix in one of a hundred nearly identical spots).
If a person actually has to edit the code or hunt down a bug themselves, wading through that pile of redundant entities will make their eyes cross.
When code is more complex than it needs to be, the compiler has a harder time optimizing it.
It's easier to generate yet another near-duplicate function than to track down and rework the dozens of existing ones just like it.
Unnecessary code doesn't just slow people down, it makes it harder for static analyzers to catch errors too.
It takes longer to compile.
Verbosity raises the odds of running into undefined behavior, or code that just doesn't do what it was supposed to.
I'm sure you could keep adding to this list.

By "verbosity" I also mean using words you don't actually understand, because they sound nice. The GenAI behind this code clearly has no idea what noexcept actually means, it just throws it in because it thinks the code looks better that way. And that's exactly why exceptions end up firing in places they never should.


vt_status vt_tensor_iter_binary_cpu_host(const vt_iter_config* cfg,
                                         vt_tensor out_h,
                                         vt_tensor a_h,
                                         vt_tensor b_h,
                                         vt_tensor_iter_loop1d_fn loop,
                                         void* user_ctx) noexcept {

  ....
  if (effective.check_mem_overlap != VT_ITER_OVERLAP_DISABLE &&
      effective.check_mem_overlap != VT_ITER_OVERLAP_ENABLE) {
    throw std::invalid_argument(
        "vt_tensor_iter_binary_cpu: invalid vt_iter_overlap_mode");
    }
  ....
}

And here's the thing: the bloated code problem falls on whoever's using the tool, not the AI vendor selling it. They're not the ones footing the token bill.

So what do you actually do? I don't have a ready-made fix. But at least knowing about it puts you ahead.

I'm leaning more and more toward the idea that PVS-Studio's static analyzer needs to get better at spotting similar code fragments. Do that, and you could close the loop between GenAI and PVS-Studio. Code would only count as done once the analyzer stays quiet on bugs and finds no duplicated functionality either.

This isn't a PVS-Studio roadmap yet, but a picture is starting to take shape, one that shows the new problems out there and how the tool could help tackle them.

Additional links:

Let’s make a programming language. Variables — Key points

Unicorn Developer — Tue, 18 Aug 2026 13:00:38 +0000

We continue the development of our toy programming language that has evolved from handling single expressions to supporting full programs composed of declaration lists. In this episode, we'll explore variable implementation, declarations, and type handling in a simple programming language interpreter/compiler.

About the speaker

Yuri Minaev is an experienced C++ developer, architect at PVS Studio, and a recognized voice in the C++ community who has spoken at CppCast, C++ on Sea, and CppCon. Over the course of ten sessions, he’ll guide you through each stage of building your own programming language.

Parsing and name resolution

Introducing variable names requires more than parsing. The semantic analyzer, or SEMA, manages the symbol table, scopes, and types. The symbol table associates names with variable declarators, allowing the language to resolve references and detect undeclared identifiers and duplicate definitions. Declarations are recorded in the current scope.

Types and implicit conversions

SEMA extracts types from expressions using a visitor. The language has error, void, int, float, boolean, and function types. Functions and void values cannot initialize variables. When an operation combines different types, the language calculates a common type. For example, int and float produce float, so int is implicitly cast. Logical and relational expressions produce boolean results, while arithmetic expressions use their operands' common type.

Building the syntax tree

Implicit casts are added to the syntax tree during construction, so the evaluator will not need to calculate types itself. It can walk the tree and execute the represented operations and conversions. Errors propagate through the tree, and invalid programs are never evaluated.

Want more?

If you want to watch other talks, follow this link.

You can also sign up for our upcoming webinars: Let's make a programming language. Functions. We hope to see you there!

If you'd like to learn more about PVS-Studio analyzer, check out our website.

See ya!

Static and dynamic analysis help when unit tests fail

Unicorn Developer — Fri, 14 Aug 2026 13:15:28 +0000

No one disputes the value of static or dynamic code analysis. However, some developers see that value as rather abstract and stop at writing unit tests. I recently came across an example from the C world that nicely illustrates how unit tests can sometimes fail to catch even the most common types of errors.

I've already discussed the bug I'm about to show you in the article "A beautiful error in the implementation of the string concatenation function." I'll briefly recap it, and then we'll look at it from the perspective of early detection.

String concatenation bug

The LFortran project had the following function for concatenating two strings into a new buffer:

void _lfortran_strcat(char** s1, char** s2, char** dest)
{
    int cntr = 0;
    char trmn = '\0';
    int s1_len = strlen(*s1);
    int s2_len = strlen(*s2);
    int trmn_size = strlen(&trmn);
    char* dest_char = (char*)malloc(s1_len+s2_len+trmn_size);
    for (int i = 0; i < s1_len; i++) {
        dest_char[cntr] = (*s1)[i];
        cntr++;
    }
    for (int i = 0; i < s2_len; i++) {
        dest_char[cntr] = (*s2)[i];
        cntr++;
    }
    dest_char[cntr] = trmn;
    *dest = &(dest_char[0]);
}

This is a classic error where the allocated buffer is one byte smaller than required. The terminal null isn't taken into account; or rather, it is, but its size is calculated incorrectly.

char trmn = '\0';
int trmn_size = strlen(&trmn);

The trmn character here gets interpreted as an empty string, whose length is zero. As a result, the trmn_size variable, whose name suggests that it stores the size of the terminal null, always equals 0. So, the terminal null is written past the end of the allocated buffer.

This is how we can fix the code (by adding +1 when calculating the argument of the malloc function):

void _lfortran_strcat(char** s1, char** s2, char** dest)
{
    if (s1 == NULL || *s1 == NULL ||
        s2 == NULL || *s2 == NULL || dest == NULL)
    {
      // Some error handling appropriate for this project.
      ....
    }
    int s1_len = strlen(*s1);
    int s2_len = strlen(*s2);
    char* dest_char = (char*)malloc(s1_len + s2_len + 1);
    if (dest_char == NULL)
    {
      // Some error handling appropriate for this project.
      ....
    }
    memcpy(dest_char, *s1, s1_len);
    memcpy(dest_char + s1_len, *s2, s2_len);
    dest_char[s1_len + s2_len] = '\0';
    *dest = &(dest_char[0]);
}

Granularity

The error is simple and straightforward. Buffer overflows are a common issue in C programs. What else is there to discuss? The bug has been found; case closed.

What got me thinking was a reader's comment about how tricky this error can be because of the granularity of memory allocation.

The malloc function doesn't actually allocate exactly as much memory as requested. It obtains large blocks from the OS and splits them into smaller chunks, adding some metadata along the way. The exact block size depends on the implementation.

Even if we call malloc(1), the allocator may still return a pointer to a block that is, say, 32 bytes in size (minus the metadata fields, leaving 24 usable bytes). This helps maintain memory alignment, typically the 16-byte one, and simplifies memory management.

The returned pointer must be properly aligned. Since malloc doesn't know what types we'll store in the allocated memory, it has to account for the strictest alignment requirement that might arise. In reality, on x86-64, malloc allocates addresses that are multiples of 16. That's why the allocator always rounds the requested block size up to the next alignment boundary.

I described the process very roughly and simplified some details. The important point is that, in reality, the code we looked at usually allocates more memory than it actually needs. If the blocks are multiples of 16 bytes, writing the terminal null into the next block will happen only when the resulting string size is also a multiple of 16. In other words, the bug has a 1-in-16 chance of actually happening (or perhaps not 16, that's just one possible value).

Now, I'd like to mention undefined behavior. Technically, the code is incorrect because it accesses memory outside the array bounds. We can't reliably predict how it will work, how the bug will behave, etc.

However, undefined behavior can also mean that incorrect code happens to work as expected. In this case, the memory manager may allocate more memory than the code requests, making it appear as if everything is working correctly.

Limitations of unit tests

We can write unit tests like these:

void Test1()
{
    char *a = "a";
    char *b = "";
    char *q;
    _lfortran_strcat(&a, &b, &q);
    int ok = strcmp(q, "a") == 0;
    printf("%s+%s=%s %s\n", a, b, q, ok ? "ok" : "err");
    free(q);
}

void Test2()
{
    char *a = "12";
    char *b = "345";
    char *q;
    _lfortran_strcat(&a, &b, &q);
    int ok = strcmp(q, "12345") == 0;
    printf("%s+%s=%s %s\n", a, b, q, ok ? "ok" : "err");
    free(q);
}

And still miss the issue. The tests pass successfully:

a+=a ok
12+345=12345 ok

Tests with short strings won't reveal the problem. Some developers might not even think to try working with long strings. Why would they? At first glance, such tests don't seem to add much value. Those devs will probably create tests for edge cases, such as empty strings, but they aren't relevant to finding the bug we're discussing.

Even with long strings, the chance of spilling into the neighboring block is only 1 in N (where N might be 16, for example). They could concatenate two huge strings, each containing 111111 characters, and everything would still work fine because the resulting 222222-character string doesn't end on a 16-byte block boundary.

More unit tests

Don't get me wrong: I'm not criticizing unit tests. They're a great tool! However, some errors can easily hide from them, and this is exactly such a case.

The issue is that it's easy to miss where the code crosses the invisible boundary of an allocated memory block. The following test creates reasonably long strings, 37 characters each. Do you think this test will cause the program to crash or create another visible problem?

void Test3()
{
    char *a = "123";
    for (unsigned i = 1; i != 35; ++i)
    {
        char *b = (char *)malloc(i + 1);
        memset(b, 'a', i);
        b[i] = '\0';
        char *q;
        _lfortran_strcat(&a, &b, &q);
        int ok = strlen(q) == 3 + i;
        printf("%u %s %s\n", i, q, ok ? "ok" : "err");
        free(b);
        free(q);
    }
}

It's impossible to say whether it will or not because we're dealing with undefined behavior. In reality, I compiled it with gcc using the -O2 optimization level and didn't notice any visible symptoms of the error, even though the memory blocks should have been corrupted. Yet the tests still make everything look fine:

1 123a ok
2 123aa ok
3 123aaa ok
4 123aaaa ok
5 123aaaaa ok
6 123aaaaaa ok
7 123aaaaaaa ok
8 123aaaaaaaa ok
9 123aaaaaaaaa ok
10 123aaaaaaaaaa ok
11 123aaaaaaaaaaa ok
12 123aaaaaaaaaaaa ok
13 123aaaaaaaaaaaaa ok
14 123aaaaaaaaaaaaaa ok
15 123aaaaaaaaaaaaaaa ok
16 123aaaaaaaaaaaaaaaa ok
17 123aaaaaaaaaaaaaaaaa ok
18 123aaaaaaaaaaaaaaaaaa ok
19 123aaaaaaaaaaaaaaaaaaa ok
20 123aaaaaaaaaaaaaaaaaaaa ok
21 123aaaaaaaaaaaaaaaaaaaaa ok
22 123aaaaaaaaaaaaaaaaaaaaaa ok
23 123aaaaaaaaaaaaaaaaaaaaaaa ok
24 123aaaaaaaaaaaaaaaaaaaaaaaa ok
25 123aaaaaaaaaaaaaaaaaaaaaaaaa ok
26 123aaaaaaaaaaaaaaaaaaaaaaaaaa ok
27 123aaaaaaaaaaaaaaaaaaaaaaaaaaa ok
28 123aaaaaaaaaaaaaaaaaaaaaaaaaaaa ok
29 123aaaaaaaaaaaaaaaaaaaaaaaaaaaaa ok
30 123aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa ok
31 123aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa ok
32 123aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa ok
33 123aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa ok
34 123aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa ok

The program will crash when i reaches 38 in the for (unsigned i = 1; i != 38; ++i) loop:

free(): invalid pointer
Program terminated with signal: SIGSEGV

Don't look for any special meaning in the number 38; it's just how it turned out. The most interesting thing here is how long the error was hiding from unit tests!

Early error detection

Such an error can be detected immediately using static or dynamic analysis.

Picrute 1—Early error detection using dynamic analysis (AddressSanitizer) or static analysis (PVS-Studio).

PVS-Studio static analyzer immediately issues a warning about an anomaly in the code: V742 Function receives an address of a 'char' type variable instead of pointer to a buffer. Inspect the first argument.

Or you can use a dynamic analysis tool, such as AddressSanitizer (gcc key:fsanitize=address). The simplest test, Test1, will immediately expose the issue.

Unit tests and dynamic analysis work hand in hand. The sanitizer detects an issue while the unit test runs. Without the test, the error may not surface until much later.

Conclusion

Static and dynamic analysis complement unit tests and other bug-finding techniques well. There's no single best method or tool, though. Static and dynamic analyzers have their own limitations and complement each other. And unit tests can uncover logic errors that analyzers are unlikely to catch.

Use them all. Although it'll require some investment at first, it'll pay off over time by catching a large percentage of bugs at an early stage in the development process. The earlier you find a bug, the easier and cheaper it is to fix (the shift-left testing approach).

Webinar on common mistakes Go developers make

Unicorn Developer — Fri, 07 Aug 2026 12:28:17 +0000

Even experienced Go developers can make mistakes. Typos, duplicated code, incorrect condition checks, and other issues may find their way into production code just like they do in any other programming language.

Many teams rely on tools such as go vet to catch common issues. But is that enough? Some bugs remain invisible to standard tools and approaches, making them much harder to spot before they affect performance or behavior.

If you've ever wondered why these issues still slip through, our upcoming live talk is for you!

What we'll cover

During the webinar, Gleb Aslamov, Senior Developer Advocate at PVS-Studio, will cover common mistakes found in real-world Go code from well-known open-source projects. The speaker will also discuss the kinds of errors that standard tools and development practices fail to detect—and how to deal with them.

Throughout the webinar, Gleb will also explain why these mistakes happen, why conventional tooling doesn't always detect them, and how developers can find them sooner.

Join us live

Follow this link to join us on August 27, 2026, at 1:00 p.m. UTC+ to learn more about common errors and pitfalls in Go.

Be sure to check your email and confirm your registration to access the webinar link!

How PVS-Studio helps enhance quality of embedded projects

Unicorn Developer — Wed, 05 Aug 2026 13:30:26 +0000

Embedded development comes with a wide variety of custom configurations, compilers, and build systems, which can make standard analysis approaches difficult to apply. To address this challenge, PVS-Studio provides a dedicated mechanism designed specifically for such environments. Let's take a closer look at how it works and see how you can use it in real cases.

Features of embedded systems

Embedded development in C and C++ powers an enormous range of devices—from electric kettles and toothbrushes to safety-critical systems such as medical equipment and aircraft control software. In these areas, the quality of software directly affects human safety. As a result, the code must be as reliable, predictable, and resilient to external factors as possible.

The need for thorough code verification in embedded systems continues to grow for several reasons:

Embedded systems interact directly with users and external data, so they must correctly handle all input.
Memory is often severely limited, making careful resource management essential.
The software must remain stable under all operating conditions and provide a high level of fault tolerance.
Many other factors also contribute to these requirements.

Embedded software targets a wide variety of platforms and use cases. Each project may rely on a different compiler, toolchain, or build system. The situation often becomes more challenging due to a "zoo" of custom-built scripts that are difficult to maintain.

PVS-Studio static analyzer offers several mechanisms specifically designed for embedded projects. They collect all the necessary information for analysis directly from the compilation process as it runs.

Specialized analysis mechanisms

All of the mechanisms described here follow the same general workflow. You start them before building your project, and they monitor every run of supported compilers throughout the build process:

C and C++ compilers from the GNU Compiler Collection (gcc.exe, g++.exe) and compatible derivatives;
Clang C and C++ compilers (clang.exe) and compatible derivatives;
Borland C++;
QCC;
Keil MDK ARM Compiler 5/6;
IAR C/C++ Compiler for ARM;
Texas Instruments ARM Compiler;
GNU Arm Embedded Toolchain;
Texas Instruments Code Composer Studio, C6000-CGT, C2000-CGT (support is coming in October);
GNU toolchain for RISC-V.

Note. If you'd like us to support a compiler that isn't currently supported, we'd be happy to evaluate adding it. You can send us a request to support a specific compiler or contact us about any issues you're experiencing via our feedback form.

After monitoring finishes, the server generates intermediate files and then runs the static analyzer.

Each mechanism targets a specific environment or use case. Let's look at them one by one.

Compilation monitoring CLMonitor.exe (for Windows)

CLMonitor.exe is a monitoring server that tracks compiler runs. Start it before building your project. Once monitoring is enabled, the server intercepts every run of supported compilers.

The compilation monitoring system follows a straightforward workflow, illustrated below:

How to start compilation monitoring

To start the monitoring process, run the following command:

CLMonitor.exe monitor

CLMonitor.exe will run in the background and track all supported compilers. To stop the process, run one of the commands described below.

You can also track only compiler runs that were started by a specific process identified by its PID. To do this, start CLMonitor.exe in the trace mode with the trace and --parentProcessID (-p) arguments.

The command for running CLMonitor.exe in this mode may look like this:

CLMonitor.exe trace –-parentProcessID 10256

If you want CLMonitor.exe to track only the build started from the same console, you can run CLMonitor.exe with the --attach (-a) argument:

CLMonitor.exe monitor –-attach

Building the project

After starting compilation monitoring, build your project using the usual workflow. Once the project build is complete, stop compilation monitoring so that you can analyze the collected data.

How to stop compilation monitoring

You can run the analysis immediately after building the project using the following command:

CLMonitor.exe analyze -l D:\ptest.plog

You can also pass additional parameters when starting the analysis:

-l is the path to the final analyzer report file;
-u is the path to the suppress file;
-c is the path to the .pvsconfig analysis configuration file;
--intermodular enables the intermodular analysis mode.

If you encounter issues while building the project and need to stop compilation monitoring without analyzing the resulting files, you can do so using the following command:

CLMonitor.exe abortTrace

The CLMonitor.exe monitoring server enables saving captured compilation data in a separate dump file. This allows you to run the analysis without rebuilding the project.

To save the dump file, use the following command:

CLMonitor.exe saveDump -d D:\monitoring.zip

where -d is the path to the final dump file.

To run the analysis using a saved dump file, use the following command:

CLMonitor.exe analyzeFromDump -l d:\ptest.plog -d d:\monitoring.zip

This command supports all the flags described above that are used to start the analysis.

The Wrap Compilers interception mode (for Windows)

As we continue the discussion of embedded system specifics, it's worth mentioning another challenge involved in analyzing embedded projects. Such projects often consist of quickly compiling C source files, and CLMonitor.exe may not have enough time to detect all source files.

To ensure the interception of all compilation processes, the monitoring server can switch to a more aggressive mode using the Image File Execution Options (IFEO) mechanism on Windows.

The Wrap Compilers intercept mode runs a special handler before each compilation process begins. It sends the necessary information to the monitoring server and then continues running the compiler.

Note. This mode requires access to editing the path in the Windows Registry:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options.

You can grant the required access to the monitoring server by running it as administrator or by giving it write permissions to the registry branch above—or for the entire registry.

To enable the interception mode in the console version of the monitoring tool, pass the --wrapCompilers (-W) flag to the monitoring server with a list of compilers, for example:

CLMonitor.exe trace --wrapCompilers gcc.exe,g++.exe

Compiler tracing (for Linux)

The compile_commands.json file is used to analyze projects on the Linux system. You can find more information on the relevant documentation page.

If generating the compile_commands.json file is not possible, you can use the compilation trace mode. To do so, install the strace utility of the 4.7 version or later. It enables the analyzer to collect essential information about project compilation during the build process.

You can build the project and track its compilation process using the following command:

pvs-studio-analyzer trace -- build_command -o /path/to/strace_out

where:

build_command is the command used to build the project;
-o is the path to the compilation trace file. If no flag is specified, a file named strace_out is saved in the CWD.

As a result of the tracing, a file named strace_out will be created by default.

Once you have obtained the strace_out compilation trace file, you can run the analysis using the following command:

pvs-studio-analyzer analyze -f /path/to/strace_out

You can also pass additional parameters when starting the analysis:

-f is the path to the file containing the compilation trace results;
-l is the path to the final analyzer report file;
-u is the path to the suppress file;
-c is the path to the .pvsconfig analysis configuration file;
--intermodular enables the intermodular analysis mode.

Visual Studio Code

You can also use compilation monitoring with the PVS-Studio plugin for Visual Studio Code.

To start compilation monitoring, use the PVS-Studio: Run compiler monitoring for C and C++ command in the Visual Studio Code Command Palette (Ctrl + Shift + P).

When monitoring starts, the plugin window containing the table will display an indicator showing that monitoring is running:

Once compiler calls are intercepted, their number will be displayed in the monitoring indicator, and the start button will appear.

You can start the project analysis by clicking the button or using the PVS-Studio: Stop monitoring and start analysis command in the Visual Studio Code command palette.

The first time you run monitoring on a project, the plugin will prompt you to edit the ./.PVS-Studio/CLMonitorAnalyzerConfig.jsonc configuration file.

Click Edit to set the following parameters:

the path to a monitoring dump file (by default, ./.PVS-Studio/lastMonitoring.zip);
the path to the configuration file or directory containing .pvsconfig files.

Click Continue to run the analysis using the default settings.

If the source code files and the build configuration haven't been changed, you can use the dump file to run the analysis. To do this, select the PVS-Studio: Start analysis from compiler monitoring dump file command from the Visual Studio Code command palette.

In PVS-Studio plugin for Visual Studio Code, you can use the Wrap Compilers mode. To enable it, open the Monitoring (C and C++) tab in the plugin settings and specify the names of the compiler executable files you want to monitor.

Note. To enable monitoring in this mode, restart Visual Studio Code with administrator privileges.

A standard for improving reliability

Fixing bugs in embedded systems after a device ships is both difficult and expensive. This may require product recalls, firmware updates, reshipping, or replacing devices entirely in the worst case. Such issues come at a high cost, both financially and in terms of reputation.

To minimize risks, errors must be detected and fixed at the development stage. When there are many errors, it's much more effective to classify and track them using industry standards.

For example, the IEC 61508-7 industry standard requires using a subset of the C and C++ languages, coding standards, and static code analyzers when designing systems with a high safety integrity level (SIL).

The automotive industry relies on the ISO 26262, which establishes functional safety requirements for road vehicles. The standard also specifies requirements for verifying software modules and recommends using static code analysis as part of the verification process.

MISRA C and MISRA C++ have become the industry standard for defining safe subsets of the C and C++ languages.

The MISRA standards provide guidelines for developing safe and reliable C and C++ software in safety-critical fields, including automotive, aerospace, medical devices, and industrial automation. These are industries where the cost of failure is exceptionally high.

MISRA improves software safety by preventing bugs and vulnerabilities and by restricting complex language features that can cause unexpected program behavior.

Its authors have scrutinized international C and C++ standards and listed every possible way to make a mistake. The MISRA C and MISRA C++ standards provide guidelines to help reduce errors, improve code readability, and enhance maintainability.

Manually enforcing code quality in large projects is both difficult and time-consuming. For this reason, MISRA strongly encourages the use of automated code quality tools.

PVS-Studio supports code analysis to ensure compliance with multiple MISRA standards. At the time of writing, it covers the following Mandatory and Required rules:

MISRA C 2012 — 80%;
MISRA C 2023 — 85%;
MISRA C++ 2008 — 33%;
MISRA C++ 2023 — 35%.

In the PVS-Studio 7.41 release, we completed work on covering the MISRA C 2023 standard, achieving 85% coverage. We're not stopping there: This year, we've already begun expanding our support for the MISRA C++ 2023 standard.

For more information on the classification of warnings according to the MISRA C and MISRA C++ standards, see the relevant section of the documentation.

When working with MISRA standards, the MISRA Compliance report is particularly useful. It assesses whether a project is compliant with MISRA C and/or MISRA C++, considering all deviations and re-categorizations.

Learn more about the MISRA Compliance report in the relevant section of the documentation.

Dangerous code fragments in embedded projects

We've looked at several ways to analyze projects for embedded systems using PVS-Studio. Now let's take a look at some real errors the analyzer found in open-source embedded projects.

We'll use several popular real-time operating systems (RTOSs) as examples. An RTOS is a specialized OS designed to ensure tasks are completed within strict timing constraints. These systems are widely used in microcontrollers, industrial equipment, electronic devices, and other embedded applications.

RT-Thread

RT-Thread, which originated in China in 2006, is developed by the RT-Thread Development Team. It's widely used in IoT devices, home appliances, and industrial equipment. It offers a well-developed ecosystem with a wide range of built-in components, coming close to being a full-fledged OS.

The project was checked as of the cfda3b3 commit.

Fragment N1

PVS-Studio warnings:

V1031 The 'memcmp' function is not declared. Passing data to or from this function can be affected. dhcp_server_raw.c 151

V1031 The 'strchr' function is not declared. Passing data to or from this function can be affected. dhcp_server_raw.c 718

V647 The value of 'int' type is assigned to the pointer of 'char' type. Consider inspecting the assignment: 'p = strchr(str_tmp, '.')'. dhcp_server_raw.c 718

#include <stdio.h>
#include <stdint.h>
// ....
static struct dhcp_client_node *
dhcp_client_find_by_mac
  (struct dhcp_server *dhcpserver, const u8_t *chaddr, u8_t hlen)
{
  struct dhcp_client_node *node;

  for (node = dhcpserver->node_list; node != NULL; node = node->next)
  {
    if (memcmp(node->chaddr, chaddr, hlen) == 0)               // <=
    {
      return node;
    }
  }

  return NULL;
}
// ....
void dhcpd_start(const char *netif_name)
{
  // ....
  char str_tmp[4 * 4 + 4] = DHCPD_SERVER_IP;
  char *p = str_tmp;
  ip4_addr_t ip_start, ip_end;

  p = strchr(str_tmp, '.');      // <=
  if (p)
  {
    p = strchr(p + 1, '.');      // <=
    if (p)
    {
      p = strchr(p + 1, '.');    // <=
    }
  }
  // ....
}

Two interesting warnings stem from the same mistake, which fundamentally changes the behavior of the entire source file. The analyzer reports that the memcmp and strchr functions aren't declared. A quick look at the included headers shows that the file is missing <string.h>.

This code still compiles in C because an undeclared function is assumed to return int by default. As a result, the analyzer also reports a second issue: an int value is assigned to a char pointer.

Such code can lead to incorrect program behavior, as demonstrated in the article "A nice 64-bit error in C". The fix is straightforward: simply add #include <string.h> at the beginning of the file.

Fragment N2

PVS-Studio warning: V614 Potentially uninitialized pointer 'GPIOx' used. HAL_GPIO.c 48

typedef enum
{
    GPIOA,
    GPIOB,
    GPIOC,
    GPIOD,
}enum_GPIOx_t;

void HAL_GPIO_IRQHandler(enum_GPIOx_t fe_GPIO, uint32_t fu32_GPIO_Pin)
{
  GPIO_TypeDef *GPIOx;              // <=

  switch (fe_GPIO)
  {
    case GPIOA:
    case GPIOB:
    {
      GPIOx = GPIOAB;
    }break;

    case GPIOC:
    case GPIOD:
    {
      GPIOx = GPIOCD;
    }break;

    default: break;                 // <=
  }

  if (fe_GPIO == GPIOB || fe_GPIO == GPIOD )
  {
    fu32_GPIO_Pin <<= 16;
  }

  if (GPIOx->RIS & fu32_GPIO_Pin)   // <=
  {
    GPIOx->IC = fu32_GPIO_Pin;

    /* user can call your application process function here */
    /* ...... */
  }
}

The analyzer warns that an uninitialized pointer is being used. The GPIOx variable is declared, but it's assigned a value in only four switch branches. In the default branch, it remains uninitialized, so using the pointer afterward results in undefined behavior.

In C, the enum parameter can receive any integer value. If this happens, execution enters the default branch, and the pointer remains uninitialized.

To fix the issue, we'll add appropriate handling to the default branch. For example, return from the function when fe_GPIO contains an unknown value:

default:
    return;

Fragment N3

PVS-Studio warning: V570 The 'RTC_DateStruct->RTC_WeekDay' variable is assigned to itself. hk32f0xx_rtc.c 986

void RTC_GetDate(uint32_t RTC_Format, RTC_DateTypeDef *RTC_DateStruct)
{
  uint32_t tmpreg = 0;
  // ....
  /* Check the input parameters format */
  if (RTC_Format == RTC_Format_BIN)
  {
    /* Convert the structure parameters to Binary format */
    RTC_DateStruct->RTC_Year = 
                        (uint8_t)RTC_Bcd2ToByte(RTC_DateStruct->RTC_Year);
    RTC_DateStruct->RTC_Month = 
                        (uint8_t)RTC_Bcd2ToByte(RTC_DateStruct->RTC_Month);
    RTC_DateStruct->RTC_Date = 
                        (uint8_t)RTC_Bcd2ToByte(RTC_DateStruct->RTC_Date);
    RTC_DateStruct->RTC_WeekDay = 
                        (uint8_t)(RTC_DateStruct->RTC_WeekDay);  // <=
  }
}

This error is quite interesting. I reformatted the code snippet because the original was too wide, which makes the issue immediately obvious here. Developers most likely copied the lines converting the value type from BCD to binary, but in the last line they forgot to call RTC_Bcd2ToByte (this is a classic mistake). As a result, RTC_WeekDay is assigned to itself, which is pointless.

The fixed code:

RTC_DateStruct->RTC_WeekDay = 
                    (uint8_t) RTC_Bcd2ToByte(RTC_DateStruct->RTC_WeekDay);

Fragment N4

PVS-Studio warning: V595 The 'cond' pointer was utilized before it was verified against nullptr. Check lines: 346, 353. pthread_cond.c 346

rt_err_t _pthread_cond_timedwait(pthread_cond_t *cond,
                                 pthread_mutex_t *mutex,
                                 rt_int32_t timeout)
{
  rt_err_t result = RT_EOK;
  rt_sem_t sem;
  rt_int32_t time;

  sem = &(cond->sem);    // <=
  if (sem == RT_NULL)
  {
      return -RT_ERROR;
  }
  time = timeout;

  if (!cond || !mutex)   // <=
  {
    return -RT_ERROR;
  }
  // ....
}

Developers used the cond pointer before checking it for NULL. Such errors are quite common in projects.

Two options are possible here:

The check is redundant because a valid object is always passed to the function input.
The check is necessary, but the compiler might remove it during optimization because it recognizes that the pointer is used further up in the code. In this case, a dereference of a null pointer occurs, resulting in undefined behavior. This article provides a more detailed look at a similar case, where the address of an object is obtained relative to a null pointer, followed by dereferencing the pointer.

To fix the error, we'll add a check at the beginning of the function. For example:

rt_err_t _pthread_cond_timedwait(pthread_cond_t *cond,
                                 pthread_mutex_t *mutex,
                                 rt_int32_t timeout)
{
  rt_err_t result = RT_EOK;
  rt_sem_t sem;
  rt_int32_t time;

  if (!cond || !mutex)
  {
    return -RT_ERROR;
  }

  sem = &(cond->sem);
  if (sem == RT_NULL)
  {
      return -RT_ERROR;
  }
  time = timeout;

  // ....
}

FreeRTOS

FreeRTOS was created by Richard Barry in 2003. Since 2017, it has been developed under Amazon Web Services. Its small kernel footprint and excellent portability across dozens of hardware platforms have made it a popular choice for microcontroller-based devices.

The project was checked as of the c73a397 commit.

Fragment N1

PVS-Studio warning: V557 Array overrun is possible. The value of 'uxTimerID' index could reach 21. TimerDemo.c 1167

static uint8_t ucAutoReloadTimerCounters[configTIMER_QUEUE_LENGTH + 1] = { 0 };
// ....

static void prvAutoReloadTimerCallback( TimerHandle_t pxExpiredTimer )
{
  size_t uxTimerID;

  uxTimerID = ( size_t ) pvTimerGetTimerID( pxExpiredTimer );

  if( uxTimerID <= ( configTIMER_QUEUE_LENGTH + 1 ) )     // <=
  {
    ( ucAutoReloadTimerCounters[ uxTimerID ] )++;
  // ....
}

This error is particularly sneaky and often slips through code reviews. Few reviewers stop to check an index boundary when the code appears to work correctly. Tests are also unlikely to catch it, which makes the error even harder to find. However, accessing an array out of bounds results in undefined behavior.

The issue stems from using a non-strict comparison <= to set the bounds of the uxTimerID index. As a result, uxTimerID can take the configTIMER_QUEUE_LENGTH + 1 value, which is also the size of the array. Accessing an element at that index results in going outside the array bounds.

The fixed code:

if( uxTimerID < ( configTIMER_QUEUE_LENGTH + 1 ) )

Fragment N2

PVS-Studio warning: V547 Expression 'i + 1 > (4 + 32)' is always false. trcSnapshotRecorder.c 831

static uint8_t writeInt8(void * buffer, uint8_t i, uint8_t value)
{
  TRACE_ASSERT(buffer != (void*)0, "writeInt8: buffer == NULL", 0);

  if (i >= MAX_ARG_SIZE)
  {
    return 255;
  }

  ((uint8_t*)buffer)[i] = value;

  if (i + 1 > MAX_ARG_SIZE)
  {
    return 255;
  }

  return ((uint8_t) (i + 1));
}

The error is that the second check, if (i + 1 > MAX_ARG_SIZE), is always false after the first check, if (i >= MAX_ARG_SIZE).

Once i passes the first check, i + 1 can no longer exceed MAX_ARG_SIZE. It's likely that one of the checks is redundant, or the second condition was intended to be different.

Zephyr

Zephyr launched in 2016 with Intel's support and is now being developed under the Linux Foundation. It targets IoT, embedded devices, and automotive systems, and features a modular architecture with a wide range of built-in subsystems.

The project was checked as of the c6da464 commit.

Fragment N1

PVS-Studio warning: V547 Expression 'conv->pad0_value > 0' is always true. cbprintf_complete.c 1224

static char *encode_float(/*....*/)
{
  // ....
  if ((decexp < 0) && (precision > 0)) {
    conv->pad0_value = -decexp;
    if (conv->pad0_value > precision) {
      conv->pad0_value = precision;
    }

    precision -= conv->pad0_value;
    conv->pad_postdp = (conv->pad0_value > 0); // <=
  }
  // ....
}

The analyzer reports that conv->pad0_value > 0 is always true. As a result, the conv->pad_postdp variable always receives the same value. Here's why the condition is always true:

As soon as execution enters the first if block, conv->pad0_value is assigned the -decexp value. Since decexp < 0, the result is always positive.
If execution enters the nested if block, the value remains positive because precision > 0.
As a result, conv->pad0_value is always greater than zero.

Most likely, the condition is redundant and can be removed. Alternatively, the initialization of pad0_value needs to be moved outside the if block. The final decision is up to the developers.

Fragment N2

PVS-Studio warning: V557 Array overrun is possible. The value of 'keep_cnt ++' index could reach 16. cbprintf_packaged.c 1143

int cbprintf_package_convert(/*....*/)
{
  // ....
  __ASSERT_NO_MSG(keep_cnt < sizeof(keep_str_pos));
  if (keep_cnt < sizeof(keep_str_pos)) {
    keep_str_pos[keep_cnt++] = arg_idx;
    keep_str_pos[keep_cnt++] = arg_pos;
  }
  // ....
}

This is a particularly interesting case. The developers correctly checked the array bounds but overlooked how the post-increment operator affects the index. Here's what happens:

the keep_cnt < sizeof(keep_str_pos) condition allows keep_cnt to reach N - 1, where N is the array size;
the first post-increment accesses the array at the N - 1 index and increments keep_cnt to N;
the second post-increment accesses the array at the N index and increments keep_cnt to N + 1.

Accessing outside the array bounds results in undefined behavior. We can fix the code by rewriting the condition as follows:

if (keep_cnt + 1 < sizeof(keep_str_pos))

Fragment N3

PVS-Studio warning: V779 Unreachable code detected. It is possible that an error is present. sched.c 345

#define z_except_reason(reason) do { \
    __EXCEPT_LOC();              \
    z_fatal_error(reason, NULL); \
  } while (false)

#define k_panic()  z_except_reason(K_ERR_KERNEL_PANIC)

void z_thread_halt(/*....*/)
{
  // ....
  if ((thread == _current) && !arch_is_in_isr()) {
    if (z_is_thread_essential(thread)) {
      k_spin_unlock(&_sched_spinlock, key);
      k_panic();                                   // <=
      key = k_spin_lock(&_sched_spinlock);         // <=
    }
    // ....
}

The analyzer detected unreachable code. The k_panic macro calls z_fatal_error, which terminates the system and never returns the control flow. As a result, the line that follows it is never executed.

Unfortunately, it's hard to recommend the right solution without more information. It's possible that this line simply doesn't belong here.

Fragment N4

PVS-Studio warning: V795 Please note that the size of the 'time_t' type is not 64 bits. After year 2038, the program will work incorrectly. clock.c 47

static void timespec_from_ticks(uint64_t ticks, struct timespec *ts)
{
  uint64_t elapsed_secs = ticks / CONFIG_SYS_CLOCK_TICKS_PER_SEC;
  uint64_t nremainder = ticks % CONFIG_SYS_CLOCK_TICKS_PER_SEC;

  *ts = (struct timespec){
    .tv_sec = (time_t)elapsed_secs,
    /* For ns 32 bit conversion can be used since its smaller than 1sec. */
    .tv_nsec = (int32_t)k_ticks_to_ns_floor32(nremainder),
  };
}

The problems of the future are already knocking at the door. In just 12 years, on January 19, 2038, this project will run into the classic Year 2038 problem.

The root cause is that time_t will no longer behave as expected. Its behavior will depend on the platform because the type stores the number of seconds since January 1, 1970. After the cutoff date, the value will overflow, causing incorrect time calculations.

How to fix issues

To keep dangerous code patterns out of your codebase, it's important to take a comprehensive approach to software quality. This may include code reviews, manual and automated testing, dynamic analysis, and other verification techniques.

Static code analysis is one of the most effective and cost-efficient ways to catch issues early in the development process. Try PVS-Studio on your project for free and explore pricing for the full version.

If you're still looking for a reason to adopt static analysis, here are five reasons why it is important for business.