DEV Community: Unicorn Developer

PVS-Studio 7.42: Testing new analyzers, expanded MISRA C++ 2023 support, and more

Unicorn Developer — Fri, 17 Apr 2026 14:11:02 +0000

PVS-Studio 7.42 is now released. This version features expanded support for MISRA C++ 2023, a plugin for Qt Creator 19, official integration with CMake, and other useful improvements. Keep reading for details.

Testing JavaScript and Go analyzers

On April 6, we launched an open testing period for our new code analyzers for JavaScript and Go. Before officially releasing these new tools, it is crucial for us to thoroughly test them and collect user feedback.

The initial versions of JavaScript and Go analyzers each include twenty diagnostic rules, a command-line interface (CLI), and plugins for WebStorm and GoLand.

One month later, a TypeScript analyzer and a new version of the Visual Studio Code extension with support for the new analyzers will become available for testing.

Additionally, the PVS-Studio Atlas code quality management platform is also available for testing. It is a new solution for managing analysis results, which enables users to mark warnings.

To take part in the testing program, please fill out the form on our website.

MISRA C++ 2023

The previous PVS-Studio release introduced coverage for 86% of the MISRA C 2023 standard.

However, our implementation of MISRA standards remains in active development. Starting with this version, we initiated the implementation of the MISRA C++ 2023 standard.

We have adapted 22 existing diagnostic rules from the MISRA group to align with the MISRA C++ 2023 standard. Additionally, it is now possible to select the MISRA C++ version within PVS-Studio IDE plugins and command-line utilities.

You can learn more about MISRA standards support on this page.

Changes to the free licensing policy

We have discontinued support for the free usage of the analyzer via special comments in the code. If you have been using the analyzer this way, you will need to get an activation key via one of the other available methods.

Changes have also been made to the free usage terms for students and educators. The student licensing program is currently paused while we refine its updated terms and conditions. We will announce them when student license applications are open again. To stay updated, you are welcome to subscribe to our newsletter.

The terms for free licensing for open-source projects, public security experts, and Microsoft MVPs remain unchanged. You can read more about these terms at this link.

New integrations

Qt Creator 19

Support for the PVS-Studio plugin for Qt Creator versions 19.x has been added. The plugin enables running analysis, reviewing warnings, and working with code without leaving a familiar development environment.

Support for the plugin for Qt Creator versions 13.x has been discontinued. We strive to maintain backward compatibility for the latest plugin versions across all Qt Creator releases from the past two years.

Learn more about working with the plugin in the documentation.

Official integration with CMake

Starting with version 4.3.0, the CMake build system includes a built-in mechanism for working with PVS-Studio. This allows analyzer warnings to appear directly during the project compilation process.

You can read more about this in the documentation.

End of support for the 64-bit error diagnostic rules

Starting with this release, we have suspended further development of diagnostic rules from the "64-bit error diagnostic rules" group. These rules will no longer be enhanced and may be disabled in future releases.

If you rely on these rules, please contact our support team so we can assist you in finding a replacement or offer an alternative solution.

Analyzer improvements

The C and C++ analyzer has reduced analysis time for template-heavy code thanks to an improved handling mechanism. Evaluation and analysis of simple functions have also been enhanced based on the context in which they are called.

The C# analyzer now includes additional debugging mechanisms. A new warning, V053, is issued when the analyzer cannot obtain built-in .NET types. The --createBinaryLogs flag has been added to log the operation of Roslyn mechanisms. More details are available in the documentation.

In the C# analyzer, we have also fixed an issue that occurred when checking non-SDK-style .NET Framework projects following an update to Visual Studio 2026 version 18.4.0 or later.

New diagnostic rules

C and C++

V1119. Preprocessing directive is present within a macro argument. This leads to undefined behavior.

C

V3232. Use of externally-controlled format string. Potentially tainted data is used as a format string.

Java

V6133. Dereferencing the parameter without a null check. Passing the 'null' value to the 'equals' method should not cause 'NullPointerException'.
V6134. It is not recommended to throw exceptions from the 'equals' method.

Articles

Here is our traditional roundup of blog articles! Over the past two months, we've posted articles exploring vibe coding, breaking down various C++ code nuances, and much more. Here is a full list of articles covering various topics.

C and C++

C

Java

Closed-world assumption in Java

Go

Exponentiation != bitwise exclusive OR

Other

Webinars

Integrating SAST into DevSecOps

As software delivery accelerates, security must move at the same speed. In this webinar, we explored how to effectively integrate Static Application Security Testing (SAST) into your DevSecOps pipeline. The session covered strategies for identifying vulnerabilities early, reducing risk, and streamlining secure development processes.

Also, the session provided actionable insights for teams looking to modernize their security practices and optimize existing workflows.

Let's make a programming language. Intro

We're kicking off a webinar series on how to build your own programming language in C++.

In this first session, we'll break down—step by step and in plain terms—what's inside the "black box": the lexer and parser, the semantic analyzer, and the evaluator. We'll discuss what these components are, why they're needed, and what exactly they do.

All recordings will be sent to registered participants after the webinar is finished.

If you'd like to see more webinars, we invite you to check out upcoming events on the webinar page.

Conclusion

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

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

How do compilers work?

Unicorn Developer — Thu, 16 Apr 2026 11:46:26 +0000

Even though we write code every day, we often view the compiler as a "black box." Today, let's explore how a compiler actually works, discuss its lifecycle, and see where trees come into play.

Compilers

To put it simply, a compiler is a translation program. It translates human-written text (source code) into machine code, which is a sequence of zeros and ones that the processor can understand.

A machine is, basically, a huge set of switches (transistors). The compiler generates instructions that enable program execution. It decides which switch to enable or disable and when to do so.

By the way, you can see the most basic form of such instructions in a Turing machine, which is a theoretical model where programs are created using only 0s and 1s. This model laid the foundation for modern computers.

If you like more challenging experiments, I invite you to check out our new webinar series, "Let's make a programming language." You'll learn what a programming language is and how to formally describe it so that a machine can understand it.

A language processing system

The compiler consists of multiple modules and is also part of a larger code-processing chain. It takes source code as input and returns binary code as output.

You can see the whole sequence in the diagram:

Let's walk through each stage to understand how the language processing system works.

Preprocessor. First, the source code is passed to the preprocessor that expands macros, includes header files, and removes comments. The code is ready to pass to the compiler only after this preparation.

Compiler. After receiving the processed code, the compiler starts its main routine. However, it doesn't output the machine code right away. First, it produces an intermediate result: assembly code that humans can understand but that is as close as possible to the processor's instructions.

Assembler. Then, the assembler comes into play. It translates commands that humans can understand into real machine code.

Linker. Large programs are usually compiled from many object files. To compile them into a single unit and link all function calls to their actual addresses, a linker is needed. It creates the final executable file.

Another approach to executing code is interpretation. Unlike a compiler, which translates the entire program, an interpreter executes commands line by line.

However, some modern languages, such as Java, employ a hybrid approach. Source code is first compiled into a special intermediate bytecode that is independent of the processor and OS. A special program, the Java virtual machine, executes it, acting as an interpreter.

What's interesting is that Java can also be compiled into machine code, bypassing the virtual machine. However, there are some nuances to this that we discussed in the article "Closed-world assumption in Java."

Today, however, we're going to talk specifically about how a classic compiler works.

How a compiler works

The compiler's work is divided into three stages: code analysis (creating a tree), code optimization, and code generation. Let's walk through each one.

Lexical analysis: From strings to tokens

When we look at code, we automatically break it down into words and see constants, variables, functions, and other parts. Lexical analysis enables the compiler to "read" the code in a similar manner.

Tokenization happens at this stage. The source text is broken down into the smallest meaningful units, which are called tokens. Each token is a pair consisting of a type and a value. A type is a number, an operator, or an identifier, while a value holds specific data, such as 12 or +. Spaces, comments, and line breaks are ignored at this stage because they aren't needed to understand the program structure.

After the lexical analysis, we get a token list instead of a long string of source code. For example, this one:

When parsing code, the lexical analyzer looks ahead by one or more characters. This enables it to accurately decipher the code for a specific language. For example, in the C language, when it encounters the > character, it must check the next character to distinguish the > operator from >= or >>.

Templates in C++ are even more complicated. The Foo<Bar> construct can refer to either a template with the Bar argument or comparison operators. How to tell the difference? The lexical analyzer can't tell on its own; it needs to know that Foo is a template name. To do this, a lexer hack is used, where the lexer uses results from a semantic analyzer that already knows which names are patterns. Modern C++ compilers integrate lexical and syntactic analysis: the parser provides the lexer with information on how to interpret the current token.

Syntax analysis: From tokens to a tree

Now we have a token sequence, but that's not a structure yet. We need to understand how they're connected. This is what a syntactic analyzer, or parser, does. It checks whether the token sequence complies with the grammar rules of the language and, in most cases, instantly generates an abstract syntax tree.

Grammar is a set of rules that describe how to put together expressions and instructions from smaller parts. For example, here's a rule for arithmetic expressions:

This is where the concepts of formal grammars come into play:

The start character is the topmost non-terminal that starts any correct code.
Terminals are the leaves of the tree, the endpoints of parsing.
Non-terminals are expandable tree nodes.

Terminals are actually tokens. In this case, number is a terminal, since it has been parsed into a token by the lexer. For a lexer, the terminal symbols are individual characters, but it groups them into larger units so that the parser doesn't have to parse them individually (for example, it groups numbers into digits).

The parser builds a hierarchy based on the grammar rules. The result is a concrete syntax tree (CST). It even has nodes for such little things as a semicolon or a comma.

Such a tree can be quite cumbersome, so compilers almost immediately convert it into a more compact form—an abstract syntax tree (AST). It contains no service nodes; only the essentials remain: operators, operands, and blocks. When discussing trees in compilers, people most often refer to ASTs.

How does a parser build a tree?

Once the lexical analyzer has converted the 42 + 10 line into the number { 42 }, op { + }, and number { 10 } tokens, the real fun begins. The parser must understand how these tokens are related to one another in order to construct a tree.

Several ways to build a tree exist, such as top-down and bottom-up parsing. They reach the same result from different sides and rely on their own grammar. However, if two different trees can be constructed for the same expression, then the grammar is considered ambiguous. These ambiguities are often resolved simply by the word order. For example, a declarative expression always takes precedence over an imperative one.

The top-down approach Parsing begins at the root (the start non-terminal) and attempts to expand it by selecting the appropriate grammar rules. Among compiler tools such as GCC, Clang, and MSVC, the most common approach is recursive descent: for each non-terminal, a separate function is written to determine which rule to apply.

The parsing process works like this: when the parser encounters the number { 42 } token, it recognizes it as literal-expr and applies the literal_expr() rule. Then, it encounters op { + } and applies binary_expr() to the + operator. After that, it does the same for the second number.

Each parsing type has a class of grammars that it can parse. Left-recursive parsing with leftmost derivation (LL(k)), with a lookahead of k (k is a constant), is a top-down parsing method. Left-recursive parsing with rightmost derivation (LR(k)), with the k lookahead, is a bottom-up approach.

The bottom-up approach This algorithm can handle a wide range of grammars and is most commonly used in BISON and YACC parsers. In this type of parsing, the parser doesn't try to "guess" the rule in advance. Instead, it accumulates tokens and, as soon as they form the right-hand side of the rule, the parser "collapses" them into a non-terminal. Parsing tables are usually used to implement such a parser. It reads the token, consults the table, and decides what to do: whether to move on to the next token or to stack the top few elements into the non-terminal.

Here's how it works, using 42 + 10 as an example:

We read number { 42 } and push it onto the stack.
We read op { + }. As the table shows, it's too early to fold, so we push + onto the stack.
We read number { 10 }. Now we see what we can fold into additive-expr. As a result, one non-terminal remains on the stack—the tree has been built.

If you're interested in seeing how modern C++ can simplify the handling of complex tree structures, I invite you to read the "How to climb a tree" article.

Semantic analysis: Giving meaning to the tree

Although the tree has been built, the compiler still needs to verify that the program makes sense from the language logic perspective. At this stage, it checks everything that grammar can't describe.

Scopes. The compiler must know which declaration each variable use refers to. It creates a symbol table as it traverses the tree. It adds an entry to the current scope when it encounters a declaration and searches for the name in the table when it encounters a usage. It returns an error if it doesn't find the name.

Type checking. Each operator must receive the correct types of operands. For example, the + operator in the 42 + 10 expression works with numbers—everything is fine. But if we wrote 42 + true, the compiler would throw an error, because Boolean values can't be added to numbers. Languages often allow implicit conversions, though. If types can be converted to one another, the compiler adds a special node into the tree, for example booltoint.

l-values and r-values. The left side of the assignment should contain the l-value, which stores the address in memory (a variable or an array element). The 42 constant doesn't have this property, so 42 = 10 is a semantic error. The semantic analyzer tracks this by checking to which node the assignment operator applies.

As a result, the tree "grows" by adding more information. Each node is assigned attributes, including the data type, a reference to the variable declaration, and conversion information. This tree is called an annotated syntax tree and is used for code generation.

The symbol table

During the semantic analysis, the compiler actively uses the symbol table. It's a data structure that stores all information about identifiers. Each entry includes a name, type, scope, and any other necessary information, as well as the memory address if it's known.

The most fascinating part is how the compiler locates names when it encounters the use of an identifier. For more information on name lookup in C++, check out the article "How far does lookup see in C++?"

IR generation

Once the semantic analysis is complete and the tree has been annotated with all necessary attributes, the compiler moves on to the next stage: generating the Intermediate Representation (IR).

IR is abstract code that is closer to machine code but isn't tied to a specific processor yet. It enables platform-independent optimizations that work on any target platform.

The most common IR type is the three-address code. It's a sequence of statements, each one performing a simple operation. Let's look at an example:

The traversal starts at the + root. The generator recognizes that two operands need to be added together. First, it generates code for the 2 left subtree, then for the * right subtree. A new temporary variable, t1, is created for the multiplication. Next, a second temporary variable, t2—which represents the result of the entire expression—is created for the + root. Here are the statements:

t1 = 4 * 3
a = 2 + t1

Optimizations

After parsing the syntax, verifying the semantics, and generating an intermediate representation, the compiler receives linear code that the optimizer can easily work with. At this stage, the compiler tries to optimize the program by making it faster, smaller, or more memory-efficient.

Let's look at this code fragment:

int a = some_complicated_function();
int b = a * 0;
std::cout << "value = " << b;

If the compiler were to simply translate the code, it would first have to evaluate a, then multiply it by zero, only then would it output the b value.

But the compiler knows arithmetic rules: multiplying by zero equals zero. This is true regardless of what a holds. So, the optimizer can fold the whole expression and replace the b variable with the 0 constant. Since a isn't used anywhere else, its evaluation can also be removed. In the end, what remains is:

std::cout << "value = " << 0;

In order to be applied, the optimization must meet the following requirements:

Correctness. The optimization shouldn't alter the program logic.
Performance boost. The optimization should actually improve the performance of most programs.
Reasonable compilation time. Optimization shouldn't make the compiler run for hours.
Executability. The required compiler task must be executable.

The compiler reorders instructions, replaces some constructs with others, and removes unnecessary elements. The result must be the same as if we had executed the source code.

This is where machine-dependent optimizations, such as register allocation, instruction selection, and instruction ordering, come into play to ensure efficient execution.

Note. In fact, static analyzers also create IR and search for redundant code during their execution, but for a different purpose. In some cases, redundancy may indicate a typo or logical error in the code. For example, PVS-Studio issues the V547 warning here, indicating that the last condition is always false.

void x(int a, int b, int c)
{
    if (a < b)
        if (b < c)
            if (c < a)
                foo();
}

Code generation

Once all optimizations are complete, the compiler finally moves on to the most critical phase: code generation. In this phase, the optimized IR is converted into actual machine instructions, including register loads, arithmetic operations, branch instructions, and function calls.

That's when the program transitions from an abstract tree to a sequence of zeros and ones, ready for execution.

Conclusion

At the beginning of this article, the compiler was a "black box" to us. Now, however, we know that it contains a whole pipeline of transformations. The entire process can be summarized as follows:

The intermediate representation lies at the heart of this entire chain. It's created from trees during the code generation phase and serves as the foundation for all further transformations. Optimization tools focus on IR, rewriting the code to make it faster, more compact, and more efficient for specific architectures.

Trees are created during syntactic parsing, assigned attributes during semantic analysis, and serve as the foundation for further transformations. Without them, the compiler wouldn't be able to "understand" the program structure.

If you want to understand the theory and learn how to build such trees yourself, check out our webinar series, "Let's make a programming language." In these coding sessions with Yuri Minaev, a PVS-Studio architect, you'll learn how to formally describe a language so that a machine can understand it.

Developing new static analyzer: PVS-Studio JavaScript

Unicorn Developer — Wed, 15 Apr 2026 13:00:03 +0000

PVS-Studio static code analyzer has been on the market for 18 years now. Over this time, it has grown to support C, C++, C#, and Java. We don't plan to stop at these languages. This article covers the development of a new JavaScript/TypeScript analyzer, which we release very soon.

Introduction

Given the enduring popularity of the ECMAScript language family among programmers, supporting an analyzer for one of the most popular language stacks was only a matter of time. As a stack grows in popularity, so does its ecosystem, and in the case of JavaScript/TypeScript, that ecosystem is the envy of many. As a programmer friend once said: "If you face some problem, there's already a library for JavaScript that solves it."

Competition from both paid and free tools is fierce. So, our goal now is to build a stable and reliable platform that we can steadily develop and expand, eventually catching up to other market solutions. That is one reason we intend to release early: the EAP has already started, and the MVP release of the analyzer is scheduled for this August.

In this article, we explain how the new analyzer works and what new architectural solutions we applied.

Language model

TypeScript tree

Every analyzer starts with a language model—more specifically, with an abstract syntax tree. After all, the analyzer needs some way to work with source code.

We began by tackling this very problem. The choice was clear: as we want both a syntax tree and a semantic model for JavaScript and TypeScript at the same time—plus support from the language developers—the TypeScript compiler has no competition. It can parse both languages, and its support is guaranteed as long as TypeScript itself evolves.

Look at the resulting AST using the factorial function as an example:

function factorial(n) {
  let result = 1;
  for (let i = 2; i <= n; i++) {
    result *= i;
  }
  return result;
}

For this, we get the following tree (see the spoiler).

AST for factorial

SourceFile:
  FunctionDeclaration:
    Identifier
    Parameter:
      Identifier
    Block:
      VariableStatement:
        VariableDeclarationList:
          VariableDeclaration:
            Identifier
            NumericLiteral
      ForStatement:
        VariableDeclarationList:
          VariableDeclaration:
            Identifier
            NumericLiteral
      BinaryExpression:
        Identifier
        LessThanEqualsToken
        Identifier
      PostfixUnaryExpression:
        Identifier
      Block
        ExpressionStatement:
          BinaryExpression:
            Identifier
            AsteriskEqualsToken
            Identifier
      ReturnStatement:
        Identifier
  EndOfFileToken

You can play with it yourself here.

You may also notice small differences between this AST and more "academic" ones. First, the tree contains tokens, even though tokens usually belong to a parse tree. Second, their names reflect visual representation rather than semantic meaning. In the example above, we have AsteriskEqualsToken, but the TypeScript compiler also has a token with the wonderful name DotDotDotToken for the spread operator.

Semantics

A syntax tree alone is not enough. Let's say we want to catch a missed assignment when replacing a character in a string:

function replaceFoo(variable: string): string {
    variable.replace("foo", "bar")
    return variable
}

Here, the result of replace isn't saved anywhere. The analyzer could issue a warning about every replace in the program, but that would produce too many false positives. To ensure that this is the replace we need, we have to verify that it is called on an object of the needed type and that the argument types match the parameter types.

How do we find out the type of the variable identifier? Manually looking up definitions for every identifier node is overkill, and outside such simple cases it's non-trivial—with hoisting it would be much more complicated.

This is where semantic code analysis comes in, helping us find variable types and scopes. And that's another reason we chose the TypeScript compiler. It can:

resolve identifiers and their types for TypeScript;
resolve identifiers and infer types for JavaScript when possible—when a literal was explicitly assigned or JSDoc was used.

In short, the compiler really has everything we need. Still, the adventure is just beginning.

gRPC

The Java team was assigned to develop the new analyzer. Perhaps it's because JavaScript matches Java by 50%. Just kidding. Or not quite kidding.

Anyway, the TypeScript compiler is written in TypeScript (as expected). Less expected is that it'll soon be completely rewritten in Go. This raises two major problems:

Total dependence on a third-party framework is a problem in itself. If the switch to Go caught us off guard, we would have to urgently rewrite the entire codebase in another language or stay on a legacy platform. Not to mention that over decades, open-source solutions may be abandoned.
As already noted, we are a Java team. Our expertise centers around this language—we've been writing in it and analyzing it for years. Switching to a new development language would erase all that expertise.

The solution was obvious—split the analyzer architecture into two applications.

A wrapper over the TypeScript compiler that builds and passes the model.
A Java-based analyzer requests first the AST from the wrapper and then semantic information when needed.

So, we wrap the model built by the TypeScript wrapper into protobuf and then pass it via gRPC. We've written two separate articles (first, second) about the intricacies of this process. Here are the key points:

When passing the model, we translate the original representation into our own.
We also perform normalization—simplifying the tree—to make the analysis simpler. For example, we ensure that ifbranches always have braces, even if the language makes them optional.
We automate the translation from a protobuf-serialized model using code generation—this makes it easy to react to changes and support new language versions.

With this approach, we managed to mitigate the drawbacks mentioned: most development happens in Java, and we can replace the current wrapper for the TypeScript compiler with any other. We'll have to do this when TypeScript 7 is released, at which point we'll rewrite our wrapper in Go to match the compiler.

Common abstract tree

Traditionally, we have built code analyzers by taking a framework in the analyzed language for that same language, and then building the analyzer infrastructure around it.

We used to reuse frameworks mainly for to the surrounding ecosystem—plog-converter and similar tools. Although in some cases we also borrowed analysis technologies, such as data-flow analysis from C++ into our own Java analyzer. The traditional approach had advantages:

It's quite fast: creating a proof of concept takes days if not hours.
When a developer writes an analyzer in the same language it targets, it improves both the analyzer quality and the developer's language knowledge.

But it also had disadvantages:

We would need people proficient in many different languages.
Duplicated functionality must be reimplemented multiple times.
Supporting new languages starts almost from scratch each time.

And that last point turned out to be decisive for us. Besides JavaScript/TypeScript and Go, there will be support for other languages? What? Yes! Stay tuned for updates :)

At this point, a thought occurred to us: why not build a common infrastructure for all languages? Well, most programming languages share many things: variables, control structures, operators, and so on. With a generalized language model, we wouldn't need to duplicate diagnostic rules, and with a common core, we wouldn't need to duplicate all the rest of the infrastructure.

CAT

The idea of a generalized tree is not revolutionary. It's usually called UAST, and JetBrains, for example, uses it for their IDEs. We liked the acronym CAT so much that we named our tree after it: Common Abstract Tree.

The idea is simple:

We don't abandon the AST for a specific language. We still need it if we don't want to lose language-specific details.
However, all nodes of a specific AST inherit common interfaces defined in CAT. If a diagnostic rule doesn't need language specifics, it can work only with these interfaces.
Since we don't want to compromise the analysis accuracy, and language nuances are often necessary, the diagnostic rules allow for extending the general rules with language-specific refinements.

I think we'll release more detailed material on this topic in the future, but for now we'll stick to general principles. We can illustrate the approach with a simplified analog of V6001, which detects identical operands in a binary operation—errors like a == a. Obviously, such a construct is valid in almost any language. It breaks down into typical language "building blocks":

The whole expression is called the same— an "expression".
The comparison operation here is a "binary operation" of "equals" type.
The left and right sides are also "expressions", which in our case have the narrower "identifier" type.

We can roughly understand what we're looking at, but it's not obvious what to do next. So next, let's look at error detection on the tree.

What is a diagnostic rule?

This is how diagnostic rules work.

A tree walker scans the AST of a specific language, stopping at each code element and running checks on them.
For optimization, checks have preliminary filtering based on the type of code element they should trigger on.
If a diagnostic rule finds a suspicious pattern, it issues a warning on that code fragment.

Let's get back to the error above. To find this error, we define a rule. It will check the binary expression's type (multiplication, for instance, is not of interest). It will also check that the left and right operands share the same type, and that these operands are the same. Handling chains of binary operands like a == 0 && b == 0 && c == 0 is less trivial, but the idea is roughly the same.

This pattern can find the error in any language, but that doesn't mean languages can't have their own specifics. In JavaScript, there is a foo && foo.bar && foo pattern. It appears in return statements where we return a variable value from a condition after a preliminary check.

For such cases, we provide several extension points for a general diagnostic rule: before it triggers; filtering intermediate results; and after the rule triggers. In our case, after the rule triggers on identical variable identifiers, we can check whether one of them is the last in the condition, thus eliminating false positives.

And the normal mode of operation—where we write language-specific diagnostics is still available. Given our strong focus on finding typos in code, we needed to keep that flexibility.

How Dr. Frankenstein assembled the analyzer from parts

As we took an unconventional path, our architecture turned out to be noticeably more complex than usual:

At the root, we have an ordinary CLI application written in Java.
The core contains the CAT model and rules for it.
For JavaScript/TypeScript, we have separate modules containing the specific language model and rule refinements.
We can substitute the JavaScript/TypeScript module with a module for another language, reusing the generalized core during the analysis.
The core and language layers also share the surrounding infrastructure, such as report generation.
An indispensable part of the new analyzer is the TypeScript server, which uses the compiler API to build the program model and provide us with the AST and semantics.

We can represent it simply like this:

Despite the increased complexity of the system, from the first tests it performed well.

The innovations didn't stop there. We also use compilation to a native image via GraalVM, which enabled us to switch to the latest Java versions. Also, we use DI based on Micronaut, and overall, we try to keep up with new industry trends.

By the way, this story is amusingly ironic. We have no continuity with the previous Java team that created Java analyzer—we didn't overlap in time. However, a spiritual continuity seems to exist. We independently came to a similar decision: not to follow the beaten path, but to explore new ways of creating analyzers and try to reuse existing work. Only they integrated data-flow analysis for C++ into Java, while we attempted to build a unified platform for analyzing different programming languages.

Plugins

To make it as easy as possible to integrate the static analyzer into the development process, we are developing plugins for the tools developers use. During the EAP, we provide a WebStorm plugin to run the analyzer from the IDE.

At this stage, the plugin allows you to:

run analysis on the whole project;
filter the issued warnings;
navigate through the code, viewing the code that triggered the warning;
view the most interesting warnings using the Best Warnings feature;
mark false positives.

Later, when the MVP is ready, you'll be able to run the JS/TS static analyzer using our Visual Studio Code extension. At the same time, the WebStorm plugin will gain more extensive functionality.

If you don't use WebStorm for development, you can still use the analyzer core via the CLI. You'll also be able to view reports—for example, in our PVS-Studio Atlas tool or in a browser.

Our testing system

For testing JS/TS analyzer, we reused our special tool called Self-Tester. It works with a base of open-source projects, performing regression testing of the analyzer. Here are the steps we follow:

download a specific version of the checked project from a GitHub repository;
build the project;
run the static analyzer via the CLI;
compare the generated report with a reference report for that project.

This approach ensures that useful warnings won't disappear as a result of changes to the analyzer's code.

Currently, the list of projects for the JavaScript Self-Tester is:

As for TypeScript analyzer, we're still working on the list of projects.

Here's an article where we describe in detail how we develop and test diagnostic rules. Overall, nothing has changed for the JS/TS analyzer.

Examples of errors

Well, what story about a new static analyzer would be complete without demonstrating what it can find? Next, we'll show you what the static analyzer found in our Self-Tester base and in various open-source projects.

TypeScript analyzer will be available later than the JavaScript one during the EAP, but we were able to test it ahead of time. Just don't tell anyone :)

So next, we'll look at errors in both JavaScript and TypeScript code.

Findings in ESLint

The first error comes from the JavaScript linter ESLint:

function isFirstBangInBangBangExpression(node) {
  return (
    node &&
    node.type === "UnaryExpression" &&
    node.argument.operator === "!" &&
    node.argument &&
    node.argument.type === "UnaryExpression" &&
    node.argument.operator === "!"
  );
}

The PVS-Studio warning: V7001 The operands of the '&&' operator are equivalent. space-unary-ops.js 109

The analyzer reports identical operands of the binary "AND" expression.

At first glance, it might seem like just an extra check, nothing critical. The method name and its JSDoc clarify the situation:

/**
* Check if the node is the first "!" in a "!!" convert to Boolean expression
* @param {ASTnode} node AST node
* @returns {boolean} Whether or not the node is first "!" in "!!"
*/

This method checks whether the expression is a unary ! operator that contains another unary ! operator. Such a construction of unary operators in JavaScript casts the expression to a Boolean type.

So, what goes wrong here? The expression !!1 at the AST level looks like this:

UnaryExpression (!)
└── argument: UnaryExpression (!)
    └── argument: value (1)

In the code snippet above, instead of checking the outer unary expression's operator, we check only the inner unary expression's operator ! twice.

Findings in Visual Studio Code

Let's move to our dear Visual Studio Code:

this._dispooables.add(
  Event.any<....>(
    _fileService.onDidChangeFileSystemProviderRegistrations,
    _fileService.onDidChangeFileSystemProviderCapabilities
)(e => {
  const oldIgnorePathCasingValue = schemeIgnoresPathCasingCache.get(e.scheme);
  if (oldIgnorePathCasingValue === undefined) {
    return;
  }
  schemeIgnoresPathCasingCache.delete(e.scheme);
  const newIgnorePathCasingValue = ignorePathCasing(URI.from(....);
  if (newIgnorePathCasingValue === newIgnorePathCasingValue) {
    return;
  }
  for (const [key, entry] of this._canonicalUris.entries()) {
    if (entry.uri.scheme !== e.scheme) {
      continue;
    }
    this._canonicalUris.delete(key);
  }
}));

The fragment is quite large, and it's hard to spot the error without hints. You can try to find it yourself if you'd like.

What does the analyzer say? The PVS-Studio warning: V7001 The operands of the '===' operator are equivalent. uriIdentityService.ts 63

To make it clearer, here's the exact snippet with a bug:

const oldIgnorePathCasingValue = schemeIgnoresPathCasingCache.get(e.scheme);
if (oldIgnorePathCasingValue === undefined) {
  return;
}
schemeIgnoresPathCasingCache.delete(e.scheme);
const newIgnorePathCasingValue = ignorePathCasing(URI.from(....);
if (newIgnorePathCasingValue === newIgnorePathCasingValue) { // <=
  return;
}
....

In the conditional statement, the same constant is compared with itself.

This may be the result of a failed refactoring. The changes appeared in this commit. There, similar code was part of the _handleFileSystemProviderChangeEvent method and looked like this:

if (currentCasing === undefined) {
  return;
}
const newCasing = this._calculateIgnorePathCasing(event.scheme);
if (currentCasing === newCasing) {
  return;
}

The erroneous fragment and this one are similar, only the naming differs. And the old snippet didn't have this error: it compared different constants.

That's not the only thing the analyzer found. Look at another code snippet:

private renderQuotaItem(
    container: HTMLElement, 
    label: string, 
    quota: IQuotaSnapshot, 
    overageEnabled: boolean = false
    ): void {
  const quotaItem = DOM.append(container, $('.quota-item'));
  const quotaItemHeader = DOM.append(quotaItem, $('.quota-item-header'));
  const quotaItemLabel = DOM.append(quotaItemHeader, $('.quota-item-label'));
  quotaItemLabel.textContent = label;
  const quotaItemValue = DOM.append(quotaItemHeader, $('.quota-item-value'));
  if (quota.unlimited) {
    quotaItemValue.textContent = localize('plan.included', 'Included');
  } else {
    quotaItemValue.textContent = localize('plan.included', 'Included');
  }
  // Progress bar - using same structure as chat status
  const progressBarContainer = DOM.append(quotaItem, $('.quota-bar'));
  const progressBar = DOM.append(progressBarContainer, $('.quota-bit'));
  const percentageUsed = this.getQuotaPercentageUsed(quota);
  progressBar.style.width = percentageUsed + '%';

  if (percentageUsed >= 90 && !overageEnabled) {
    quotaItem.classList.add('error');
  } else if (percentageUsed >= 75 && !overageEnabled) {
    quotaItem.classList.add('warning');
  }
}

As with the previous fragment, I suggest you find the error yourself first.

The PVS-Studio warning: V7004 The 'then' statement is equivalent to the 'else' statement. chatUsageWidget.ts 102

It refers to the following condition:

if (quota.unlimited) {
    quotaItemValue.textContent = localize('plan.included', 'Included');
  } else {
    quotaItemValue.textContent = localize('plan.included', 'Included');
  }
  ....
}

Both then and else branches are identical, so the check doesn't make sense. Only the project authors know what was intended here.

And we're moving on. Finally, let's look at two interesting spots in VS Code.

Here's the first one:

for (const namedImport of namedImports) {
  const isTarget = 
    namedImport.name.getText() === functionName || (namedImport.propertyName &&
        namedImport.propertyName.getText() === functionName);
  if (!isTarget) {
    continue;
  }
  const searchName = namedImport.propertyName 
                        ? namedImport.name 
                        : namedImport.name;
  const refs = service.getReferencesAtPosition(
    filename, 
    searchName.pos + 1
  ) ?? [];
  for (const ref of refs) {
    if (ref.isWriteAccess) {
      continue;
    }
    const calls = collect(
        sourceFile, 
        n => isCallExpressionWithinTextSpanCollectStep(ref.textSpan, n)
    );
    const lastCall = calls[calls.length - 1] as ts.CallExpression | undefined;
    if (lastCall) {
      localizeCallExpressions.push(lastCall);
    }
  }
}

The PVS-Studio warning: V7012 The conditional expression always returns the same value. nls-analysis.ts 186

It refers to this line:

const searchName = namedImport.propertyName 
                      ? namedImport.name 
                      : namedImport.name;

Regardless of the condition, searchName will be equal to namedImport.name. This fragment should probably look like this:

const searchName = namedImport.propertyName 
                      ? namedImport.propertyName 
                      : namedImport.name;

And the second spot — similar, but in a different place:

const passiveStyles = {
    borderColor: hcBorderColor 
                    ? hcBorderColor.toString() 
                    : observeColor(
                        editorHoverForeground, 
                        this._themeService
                    ).map(c => c.transparent(0.2).toString())
                     .read(reader),
    backgroundColor: getEditorBackgroundColor(this._viewData.editorType),
    color: '',
    opacity: '0.7',
};
const editorBackground = getEditorBackgroundColor(this._viewData.editorType);
const primaryActionStyles = derived(
    this, 
    r => alternativeActionActive.read(r) 
        ? primaryActiveStyles 
        : primaryActiveStyles
);
const secondaryActionStyles = derived(
    this, 
    r => alternativeActionActive.read(r) 
        ? secondaryActiveStyles 
        : passiveStyles
);
// TODO@benibenj clicking the arrow does not accept suggestion anymore
return ....

The PVS-Studio warning: V7012 The conditional expression always returns the same value. inlineEditsWordReplacementView.ts 222

Here it refers to this line:

const primaryActionStyles = derived(
    this, 
    r => alternativeActionActive.read(r) 
        ? primaryActiveStyles 
        : primaryActiveStyles
);

As we dug into the source code, we got the impression that this is the result of a failed refactoring. The following commit introduced many changes, and these lines are among them. Before the fix, this snippet looked like this:

const primaryActionStyles = derived(
    this, 
    r => alternativeActionActive.read(r) 
        ? passiveStyles 
        : activeStyles
);
const secondaryActionStyles = derived(
    this, 
    r => alternativeActionActive.read(r) 
        ? activeStyles 
        : passiveStyles 
);

Now, in the first ternary operator, then and else expressions are identical.

Findings in Overleaf

Let's move to the Overleaf project.

Remember earlier we touched upon the replace methods annotation? That wasn't for nothing. Look at the following code snippet:

/**
 * Sanitize a translation string to prevent injection attacks
 *
 * @param {string} input
 * @returns {string}
 */
function sanitize(input) {
  // Block Angular XSS
  // Ticket: https://github.com/overleaf/issues/issues/4478
  input = input.replace(/'/g, ''')
  // Use left quote where (likely) appropriate.
  input.replace(/ '/g, ' '')                       // <=
  ....
}

The PVS-Studio warning: V7010. The return value of function 'replace' is required to be utilized. sanitize.js 14

If you look at the line highlighted by the analyzer, it becomes clear that there's a typo: the changed value of replace in the second line of the method remains unused.

At first, this error seemed critical to us, as the comments and JSDoc show that this method sanitizes external data. But then it became clear that the line pointed out by the analyzer is only a cosmetic change. This replace formats quotes, replacing closing quotes at the beginning of a phrase with opening ones. Still, if the error had occurred one line earlier, the consequences would have been more severe.

The analyzer found another error in this project:

if (change.isIntersecting) {
  videoIsVisible = true
  if (videoEl.readyState >= videoEl.HAVE_FUTURE_DATA) {
    if (!videoEl.ended) {
      videoEl
        .play()
        .catch(error =>
          debugConsole.error('Video autoplay failed:', error)
        )
    } else {
      videoEl
        .play()
        .catch(error =>
          debugConsole.error('Video autoplay failed:', error)
        )
    }
  }
}

The PVS-Studio warning: V7004. The 'then' statement is equivalent to the 'else' statement. index.js 39

Here, the behavior in both then and else branches is identical. This is likely due to code copying, and the behavior in one of the branches should differ.

In a subsequent commit that touched this file, the behavior was changed, and the issue disappeared.

Finding in Prisma

The next project is Prisma.

The error appeared in the following code:

export function strongGreen(str: string): string {
  return `\u001b[1;32;48;5;22m${str}\u001b[m`
}

export function strongRed(str: string): string {
  return `\u001b[1;31;48;5;52m${str}\u001b[m`
}

export function strongBlue(str: string): string {
  return `\u001b[1;31;48;5;52m${str}\u001b[m`
}

The PVS-Studio warning: V7002 The body of a function is fully equivalent to the body of another function. customColors.ts 5

The analyzer reports that the bodies of the strongRed and strongBlue functions are identical. What's going on inside them?

These functions return specially formatted strings to display styled text in various terminals. They are called ANSI escape sequences. If you've never heard of them, let's see how it works using the return value of strongRed as an example:

\u001b[ is a command that the terminal interprets as a special signal: "a text formatting command is coming".

Then comes the string [1;31;48;5;52m. These are text display settings:

1 makes the text bold;
31 makes the text red;
48 indicates that the following settings will control the background color;
5;52 sets the background to a color from the 255-color RGB palette, corresponding to index 52;
m applies these styles to the text;
${str}is the text to which all these styles apply;
\u001b[m is a command that resets all previously applied styles for the subsequent text.

Let's get back to the error. Both the strongRed and strongBlue functions return the same red text color (31) and the same background color (52).

For strongBlue, the text color obviously should be blue (index 34), and the authors should also consider the background color.

If you're interested, you can read here more about what ANSI escape sequences are and how they work.

Findings in React

Our demonstration continues with the well-known React project.

Here's the code:

for (const property of value.properties) {
  if (property.kind === 'ObjectProperty') {
    effects.push({
      kind: 'Capture',
      from: property.place,
      into: lvalue,
    });
  } else {
    effects.push({
      kind: 'Capture',
      from: property.place,
      into: lvalue,
    });
  }
}

The PVS-Studio warning: V7004. The 'then' statement is equivalent to the 'else' statement. InferMutationAliasingEffects.ts 1771

The same warning we saw earlier, but now in TypeScript code. The expressions in then and else branches are identical. Either this is the result of a failed refactoring, which can be very misleading, or it's a real error.

Finding in jQuery

Finally, a simple error from the jQuery project:

var fullscreenSupported = document.exitFullscreen ||
  document.exitFullscreen ||
  document.msExitFullscreen ||
  document.mozCancelFullScreen ||
  document.webkitExitFullscreen;

The PVS-Studio warning: V7001 The operands of the '||' operator are equivalent. gh-1764-fullscreen.js 13

Here, document.exitFullscreen appears twice in the condition.

Such errors may indicate that, as a result of copying code, the condition contains the wrong value. In this case, it's likely just an extra check. Still, we need to be very careful with such fragments.

Conclusion

We've shown you our big effort—the new PVS-Studio analyzer for JavaScript and TypeScript. But in reality, what we have now is only the tip of the iceberg. Although, as you may have noticed, it can already find errors.

To make the analysis even more advanced, besides the AST and semantics, we still need to implement many more technologies inside the analyzer. There is a whole bottomless ocean of what an analyzer can do:

data-flow analysis;
function annotation;
interprocedural context-sensitive analysis;
intermodular analysis;
alias analysis;
taint analysis;
and much, much more.

In short, we have plenty to do, and the work may never be truly finished. But the more we do, the better and deeper our analysis will become.

However, we've made a great start: we've laid the foundation for JavaScript and TypeScript analyzers, a basic set of diagnostic rules, and a platform for implementing new analyzers. Besides refining the analyzer, we'll implement various integrations and generally improve the user experience.

As part of the EAP, the analyzer for the Go language is also available. We've already posted several articles about the errors we found with it:

Here's another article similar to this one on how to implement your own analyzer for Go.

If you want to try our new analyzers, you can try them here.

With that, we'll say goodbye. See you soon!

New webinar session on how to make a programming language with lexer

Unicorn Developer — Wed, 15 Apr 2026 09:36:59 +0000

PVS-Studio continues a series of webinars on how to create your own programming language using C++.

In this session, we continue building our own programming language from the ground up. Previously, we covered how terminal symbols fit into a grammar. Now we move one layer deeper: the lexer.

The lexer is the part of the parsing pipeline that operates on terminal symbols. It takes a raw input stream and turns it into a sequence of tokens — classifying lexemes into meaningful units. This process, as you know, is called tokenization.

We won't stop at theory. During the webinar, we'll walk through how a lexer is actually implemented in code.

This session is aimed at developers who want to go beyond using languages and start understanding how they work under the hood.

If you missed our previous webinar sessions, don't worry! You can familiarize with them on our YouTube channel or our website.

First talk

Let's make a programming language. Intro on YouTube

Let's make a programming language. Intro on the official PVS-Studio website

Second talk

Let's make a programming language. Grammars on YouTube

Let's make a programming language. Grammars on the official PVS-Studio website

If you want to get the videos earlier, all recordings will be sent to all registered participants after the webinar is finished.

Don't miss the opportunity to create your own language with the experienced developer.

It's going to be engaging and approachable.

Join new webinar!

Let's make a programming language. Lexer

P.S. And don't forget your inbox to confirm the registration!

Changes to PVS-Studio's free licensing policy

Unicorn Developer — Fri, 10 Apr 2026 11:56:04 +0000

We have updated licensing terms regarding the free use of our tool. Here is a breakdown of the changes.

PVS-Studio static code analyzer offers multiple free licensing options. Let's discuss how they will change and what options are now available.

Previously, you could use the analyzer for free by adding special comments to the source code and entering an activation key. Since April 2026, this licensing option is no longer available. If you have been using the analyzer this way, please obtain an activation key via one of the other ways.

The changes affect the free access to PVS-Studio for students and teachers. We have suspended the student licensing program while we update its terms and conditions. Our goal is to create a new academic licensing system that is convenient and easy for individual users and educational institutions to understand.

We will notify you when academic licenses are available again. To make sure you don't miss the news, we recommend subscribing to our newsletter.

Free licensing terms for open-source projects, public security experts, and Microsoft MVPs remain unchanged. You can learn more about them here.

If you would like to check your project using PVS-Studio static analyzer, you can get a trial license.

Game++. Part 1.1: C++, game engines, and architectures

Unicorn Developer — Thu, 09 Apr 2026 11:57:46 +0000

This book offers insights into C++, including algorithms and practices in game development, explores strengths and weaknesses of the language, its established workflows, and hands-on solutions. C++ continues to dominate the game development industry today thanks to its combination of high performance, flexibility, and extensive low-level control capabilities.

Why C++?

Despite its seemingly archaic nature and complexity, C++ remains the mainstream language for developing games and game engines. The reason lies in the unique balance between low-level control and high-level abstractions, which is critically game development.

On the one hand, C++ provides full control over system resources. Developers can manage every memory byte, optimize processor cache usage, and build synchronization and parallel execution systems tailored for specific architectures. C++ allows developers to create code that efficiently runs on low-end PCs, past gen consoles, or mobile devices. It also makes it possible to manually manage memory and data placement to maximize cache efficiency, which is crucial for achieving high performance.

On the other hand, modern C++ provides powerful high-level abstractions for building complex systems. Features such as classes, inheritance, templates, containers, smart pointers, RAII, and lambdas enable the development of large-scale architectures with modular logic, entity systems, and event-driven mechanisms. When used wisely—without excessive use of templates and metaprogramming—the code remains expressive and maintainable.

Other high-level programming languages, such as Python, JavaScript, C#, and Java, offer undeniable advantages, including automatic memory management, convenient syntactic sugar, extensive standard libraries, and significantly improved readability. This is why they are popular among designers, technical artists, and UI programmers for scripting tasks in games. However, these languages have serious drawbacks when it comes to developing game engines. Their reliance on virtual machines or managed runtime (JVM. CLR, etc), unpredictable garbage collector behavior that can block execution at the worst possible moment, lack of precise control over execution time, dependence on external solutions, and suboptimal memory layout schemes less suitable for performance-critical subsystems.

Such limitations are unacceptable in the realm of game development, especially at the engine level. Garbage collectors, extra memory overhead from virtual machines, or inefficient use of the processor cache can cause random freezes and frame rate drops. Physics simulations, rendering systems, netcode, and core engine logic require predictable performance, maximum resource efficiency, and low tolerance for latency spikes and instability.

C++ remains relevant in the gaming industry, not because it is the best option, but because the alternatives are too abstract to solve the real technical challenges of game systems. This is a conscious trade-off: the language is complex and potentially dangerous, but when used correctly, it offers the efficiency necessary for creating modern games. As long as performance and resource control requirements remain mission-critical, C++ will continue to be a key player in the game development industry.

What is a game engine?

Back in the day, when game engines were simple, writing your own was a no-brainer because if you didn't have an engine, you basically didn't have a game. Some people would buy someone else's engine and enjoy the beauty of reinvented wheels, while others would spend months or even years creating their own.

To understand how, and more importantly why, certain mechanisms are used within a game or engine to identify, locate, and eliminate performance and architecture issues, it's necessary to understand how game engines work and how they are created.

John Carmack once said, "The right move is to build your own engine," though many would argue that it's not that simple. However, Doom's "father" is widely known for his contributions to game engine development. He also frequently criticized off-the-shelf engines in general, advocating for in-house technological solutions. His philosophy is consistent: having an in-house engine gives developers complete control over the technology and the power to create solutions tailored to their projects' specific needs.

Well, everybody's got a point, and there's no single way to do things—it depends on the situation. Perhaps creating an engine isn't as difficult as it seems? But why bother doing it at all? What does it really mean to "create a game engine"?

I've worked with various game engines and built a couple of my own from scratch, two of which ended up in the trash. Three proprietary games were released on my third one but saw little success, and that engine was sold to a studio for some sum 15 years ago. I've seen developers using other off-the-shelf engines, complaining about issues, and devising their own solutions. I've studied—and continue to do so—the source code of other engines, both open-source and proprietary.

My experience may be somewhat biased, though: I've always wanted to create strategy games; however, most of the projects I've worked on have been shooters.

The first key question is: why do you want to do it?

Deciding to create a game or a game engine may seem like either a crazy idea or a genius one. Well, it's actually both. This is one of the cases when the journey is way more exciting than its destination.

...Firstly, secondly, and thirdly, it's a lot of fun, I promise!

Developing an engine is like playing with LEGO, but for adults and usually alone. You can add rendering, particle systems, and hot-reloading for scripts. You'll laugh, be amazed, and possibly even curse, but one thing's for sure: it won't be boring!

...Fourthly, companies will pay good money for such professional experience.

The fact you went through all the trial and error means you've gained something you can't learn in any textbook—a hands-on understanding of how a game engine works under the hood. Real-world experience is the greatest asset in the job market, and game studios are willing to pay handsomely for an in-depth knowledge of how game technologies work. While most people know how to use off-the-shelf solutions, when an issue pops up at the engine level, they need someone who's been there and done that—someone who knows where to look for the root of the problem.

...You'll definitely learn a lot along the way.

This will help you better understand not just engines, but other things as well. You'll develop real engineering intuition, grasp the concept of "heavy algorithms," learn why loading textures in a frame is a bad idea, and what are cache-friendly data structures designed to maximize the usage of processor cache memory.

This kind of knowledge comes from personal experience, not books. When you eventually stop working on your engine—which you most likely will—you will approach game and software development differently.

...By the way, speaking of a trash can...

Based on experience, that's where your first engine will end up, and so will your second one. This is okay—it's just how learning works. You might've heard of the "three systems" rule: the first system is a trial run, the second tries to do everything "right," and the third one actually works. So, don't be afraid to code, get rid of bad ideas, and start over. Each "failed" attempt doesn't waste your time; it gives you invaluable experience that brings you closer to creating that third system that will actually work.

...Your engine is as free as your spare time after work.

As it turns out, it's not free at all. These are hundreds of hours spent in the evenings and late at night. These are internal debates. These are refactorings of what you enthusiastically wrote two weeks ago. These are "nearly functional" prototypes, and while you may say, "I'll finish the UI later," what you gain in return is understanding and confidence in your decisions.

...You can and should change everything to suit your wants and needs.

Want to hot-reload JavaScript configurations? Then you'll need to learn how JavaScript and its virtual machine work. Tired of the old way to load textures? Create your runtime atlas directly from disk files. The only real limits here are your skills and the amount of time you have. Bizarre ideas are good—they create unique solutions.

...You have full control over all the inner workings.

What systems are involved, how the world update works, and what data structure stores game objects. You won't have a "black box," only a call stack and an urge to streamline everything.

...You can use your favorite programming language.

Like Rust? Use it! Prefer C++? Welcome to the pain club. Some people write game engines in Go. I've seen engines written in Lua, Python, Haskell, and even Erlang. I haven't seen one written in COBOL yet, but I bet it exists somewhere. What matters most is that you know why you picked the particular language.

...You can keep the distribution tiny.

For example, the binary file for my pet project is about 2 MB. It contains scripts, settings, and even some assets. The rest loads from the disk. For a small game, this is a luxurious dream, especially compared to engines where even a "Hello World" script weighs 200 MB.

...You can release your engine to the public.

And that's a great idea. Firstly, to see how others use it. Secondly, to find those who can actually compile it. Only a few will succeed—about 0.1% of those who downloaded the engine. They are the right people to bring into your team, though. By the way, Epic Games did something similar: active contributors to Unreal Engine were offered official jobs.

...You can even sell it.

Just be careful, because supporting an engine for other people's whims is a different kind of hell. They'll inevitably ask you to "make it just like in Unity, but different." This is an endless struggle.

...You'll never be disappointed that the engine developers didn't implement the feature you want!

You're the developer here. Want a new navigation system? Implement it. Need to expand the save system? Go ahead. You won't get turned down with these bug report replies like, "Scheduled for Q5 next year."

...Finally, about tech interviews.

Having your own game engine almost always sparks an interesting conversation. Now, instead of just answering questions, you can confidently ask some of your own: "How do you update game objects? How does asset loading work?" At that point, people start listening. They realize they're talking to an engineer who has created their own solution and isn't afraid to discuss it—not just a programmer.

For me, the first two points and the last one are the most important. Learning is fun, learning while creating a game is twice as fun. I also really enjoy programming, pushing the boundaries of what a language allows, and delving into the complex details and subtleties of algorithms and systems. Well, meaningful conversations during interviews are a nice bonus.

Game developers always complain about engines, no matter how powerful and convenient they are: this doesn't work, that is broken, this new feature doesn't support that old one thing, and that old feature was requested ten years ago, but still nothing has been added. Of course, this is all for a reason—if you've ever worked for a big company, you'll totally get what I mean. However, blaming someone else is always easier than taking responsibility. If you need some new feature, why not just implement it yourself? Well, you can't, the engine doesn't belong to you. It's someone else's, but the disappointment is still yours. This is hardly surprising. Just as it's hardly surprising that the desired feature will be added to your engine when you really need it.

By the early 2000s, the term "game engine" had become part of developers' vocabulary. However, most projects were still custom-built, and almost all of the technology was written from scratch, including custom rendering engines, animation systems, and physics engines. It used to be common practice to build an engine tailored to a specific game's genre, platform, and technical limitations. The industry has changed significantly since then: games have evolved into commercially viable, mass-market products, and development technologies have become more standardized and modular. Modern game engines, such as Unreal Engine, Unity, CryEngine, and Source, as well as the proprietary tools of major studios, have evolved into comprehensive SDKs that empower developers to create entire game franchises across various genres on a unified technological foundation rather than just a single project.

Although engine implementations can greatly vary, a relatively stable set of key subsystems had emerged by the mid-2000s: graphics, physics, animation, audio, AI, UI, system logic, replication and networking, in-game scripting, data systems, etc. Moreover, specific patterns and architectural approaches have begun to emerge within these components, recurring from project to project. These include ECS (Entity-Component System), behavior trees (BT), deferred rendering, and rollback-based concurrency control system. However, developers had to gather information on these topics piece by piece: an article here, a talk at GDC there, or a code snippet from GitHub.

There were books on graphics, physics, and AI architecture, but those were just scattered bits of knowledge. Almost no resources tied everything together by explaining not only what these things are, but also how they work under the hood and how to design game architecture while balancing technical limitations and production realities, as they did at GEA.

The second key question is: do you really need it?

Personal projects are always challenging and require crazy amounts of time. Of course, a lot depends on your end goals, but don't expect to build an Unreal Engine clone in a year. After all, it took a team of highly skilled engineers twenty years to develop the engine as we know it today, and the community has also contributed to its development. You'll always feel like something is missing in your own game engine. It takes many years of hard work to achieve even a fraction of capabilities and user-friendliness that mature tools offer.

A custom-built game engine can rarely compete with major industry ones such as Unreal Engine, Unity, CryEngine, or Godot. A game engine can compete only if there's a large, well-funded studio behind it. However, this book is probably not for those folks, since they've likely already got their own tool or are using one of the ones listed above.

Keep in mind that rarely pays off for small teams. There won't be a moment when it suddenly starts generating generous profit. No, it's unprofitable even for industry leaders. Games make money, not engines... According to Epic Games' report, the cost of developing Unreal Engine over the past four years alone exceeded $160 million. It's as if every year they release a new AAA game that we can't even play!

In 99/100 cases, game engine developers never make it to the actual game if their goal is to develop the engine itself. This path leads straight to the game being canceled. Most people may consider someone who wastes time developing their own engine to be a silly person.

Advice

If you want to release your game as quickly as possible, just go with a ready-made engine and use the features it offers. If you want to grow as a developer and lay the foundation for future projects beyond game development—and if you have enough time, energy, and patience—then go for it! A custom-built game engine is probably the best way to apply your knowledge. Plus, once you've created a solid base, you can reuse it as much as you want, improving it with each new game.

Libraries + cmake != Engine

Since you've read this far, I haven't convinced you to quit this thankless job. Well, let's move on then...

Can we call SDL/SFML/Allegro game engines, considering that tons of indie games have been made using them? Definitely not—these are libraries for wrapping platform code, although they do enable many of the basic game engine features. What about Vulkan/DX12? Absolutely not—these are graphics APIs. And what about FMOD/WWISE?

Again, no—however, they can be used to create a two- or three-dimensional scene, albeit an audio one. So, let's summarize:

Libraries + API != an engine either

Now, imagine a small project about exterminating spiders and building a base on another planet, which combines Allegro, DX11, and stb (a set of different header-only solutions for all kinds of situations) to draw moving sprites on the screen. You probably recognized Factorio from this description. It all started with the demo version on Allegro and just a few sprites:

Allegro + API + stb + talent == Factorio

Is it a game engine? The answer is still no, but we're getting closer: a game engine doesn't exist without a game (or games) built on it. Until a game is released, it's just a set of libraries glued together using CMake. Can a game engine be just a combination of graphics, animation, and user input processing? So, the conclusion is as follows:

Factorio != the engine && Factorio == the game

A game engine without a game is just a collection of tools, libraries, and other components designed to help create games. A game without an engine is still a game. If you think that such a definition of an engine without a game is vague and almost useless, you're right.

Do you really need complex material editors and miles of shaders, seamless geometry and global illumination for it, 3D physics with inverse kinematics, and network game support if you're making a 2D pixel-art platformer?

Unreal Engine has all these features, and they work pretty well, but do you really need them all? They require experience, time to get used to, and knowledge of how to configure and use them. A simple platformer game must only handle input, render sprites, maybe even display raw .png files on the screen, and play sound. You can learn all this in a couple of days from free tutorials on YouTube. You'll spend these evenings doing something useful, rather than struggling with the character controller in the editor. Finally, you've reached the main point of the whole endeavor—creating your game.

But what if you'd want to create an AAA blockbuster with next-gen graphics, physics, and so on? Well, then you'd need all these complex systems. It would also take a few decades of free time, or a team of talented engineers working full-time exclusively on the engine, to bring it all to life. Yes, modern game engines have indeed moved hopelessly far away from retro platformers.

Still, most game engines have an architecture that integrates all these subsystems into one framework. Not all of them—at least not yet—but it's important to understand that a game engine can contain only some of these features and still be considered a game engine. Not every game needs all these features at once; otherwise, no indie game would ever be released. You can design a small engine specifically for your game. But let's be honest—big game engine capabilities spoiled us, so we expect the same performance from everything else.

Some useful stuff

However, if the engine was designed specifically for a game, then having fewer features is perfectly acceptable. No matter how you develop games—whether on your own or someone else's engine, from scratch, or building on the ruins of a previous project—you'll start to notice recurring patterns. Everything that seemed like a "temporary solution" at first will eventually either become part of the foundation or be tossed in the trash. This is how the standard set of essential components emerges. First things first—when it comes to visual level and UI editors—no need to manually write levels, even if it's just a quick prototype in an evening.

When you already have something moving on the screen, the next issue inevitably appears—updating the logic. A rather simple approach is to put everything in the update function (Game::Update()), updating whatever reaches it in time. Then, you add the update priority, followed by the dependencies between systems, and then the question arises: if physics runs separately, what about the collision-based logic? Even if the game is small, it's better to design the logic as an independent system than as a series of "crutches" dependent on the array element order. Components work best if they know nothing about each other—they subscribe to events and don't care what invokes them.

Next comes the universal issue of the scene/level system. It seems obvious: you have a menu, gameplay, and cutscenes. However, when a level loads within another level, then one game mode switches to another without exiting to the menu; when it's necessary to "freeze" a scene, overlay a tutorial, and then return back—that's when the scene system falls apart if it wasn't designed for these cases. A scene isn't just a list of objects; it's a managed container of logic, data, dependencies, and transitions.

Speaking of objects, it's impossible to overlook the entity manager. Though it may seem useless and redundant at first, it proves to be the core of the entire architecture: It's responsible for creation, destruction, identification, tagging, access to components, and sometimes even debugging.

By the way, when it comes to saving, there's a game state serialization system. Some people think the only reason to use it is to save the game, but it's actually essential for everything. Auto-saving, passing states between scenes, saving configurations, replays, and rollbacks—it's amazing how many problems disappear when you can "put everything in a box and restore it."

And finally, the variable inspector. I'm not referring to a full-fledged debugger, but rather a panel where you can see variable values, ticks, and flags in real time. Where you can pause to check what a specific NPC is doing, change its behavior, enable debug information, and see how many bugs disappear simply because you finally noticed what's going on in the game logic.

Programming

It may seem strange, but traditional programming practices aren't mandatory for implementing game logic, and it'd be enough to explore visual programming systems (Blueprints, VisualScript, and ICS), which have been around for decades and allow developers to create complex mechanics without writing code manually. These systems are especially popular among designers and artists who want to prototype ideas quickly, without diving into the programming language syntax.

Designers do write code; visual programming is a legitimate form of programming, it's just that constructs like class, if, and for have another form. However, the essence lies not in forms, but in practical aspects. If you want to implement visual scripting in the game engine, you'll need to create specialized tools: node editors, visual debuggers, data-flow diagrams, optimizers, and much more. This significantly complicates engine development. For example, in Unreal Engine, Blueprints are backed by a huge amount of low-level C++ code, comparable in scale to the renderer or animation engine.

Classic code remains the most versatile and flexible way to implement logic, but it's gradually losing ground. It doesn't depend on the limitations of visual tools and allows working closer to system-level resources. However, the classic approach entails well-known problems, such as recompilation, halting the engine for rebuilds, and the time lost in these processes. And it's worth noting that training designers to work with different programming languages (for example, C++) results in high financial and time investment, and the cost of a mistake is the same as for a game programmer—an error can still crash the engine.

Main window

Most games need a window to run in—even browser games are no exception here. The window can be either the entire web page or a specific <canvas> element where the game is executed. Windows are usually created using platform-dependent mechanisms. These low-level interfaces are often cumbersome and inconvenient. What's more, you need to write separate code once for each platform (Windows, Linux, macOS, iOS, or Android) to create a window—but you rarely revisit this block afterward.

You need not only the window; there is also a graphics API context (OpenGL, Vulkan, or DirectX), which is also created via messy platform-dependent calls. Once again: you either implement them once yourself, or use a ready-made library (SDL2, GLFW, SFML, or one of many others). After creating the window, the next step is to set up the game loop—this is what will handle events, update the game logic, and render each frame.

Gameplay loop

The gameplay loop is what unites all games and game engines, although it may be veiled within the engine, replaced by abstractions or handler functions (callbacks). Ultimately, the gameplay loop code looks like this:

int main()
{
  createWindow();
  init();

  while (isRunning())
  {
    handle(inputEvent());
    updateFrame();
    drawFrame();
  }

  shutdown();
  destroyWindow();
}

The gameplay loop runs the game—without it, the main function would just end, causing the game to crash. There are many ways to expose a loop using the engine's API: it can be fully explicit, when the engine user writes something like while(engine::isRunning()) in their main function, or find it in the depths of the engine, for example, in some function like engine::run(), which in turn calls some user-defined functions (callbacks). Whatever you choose, you'll still need a gameplay loop.

User input

This is one of the foundations of any game, even if the player only has to click a pixelized cookie. The most basic input processing relies on platform-dependent APIs (WinAPI, X11, or Cocoa), which are often awkward to work with: they're not complex, but very verbose and require separate code for each supported platform. However, almost all of these APIs can extract events into an event-handling function (for example, Game::pollEvents()), which can be used to retrieve user events sequentially.

When it's time to integrate input into the game engine, you can use various approaches. One option is to provide users with direct access to the event system. In this case, the game developer calls events via pollEvent() and decides how to handle them. The basic structure of event processing usually looks like this: in the gameplay loop, the event-handling function is called at each iteration, parsing all incoming events are sequentially. Depending on the event type, the corresponding functions are called or appropriate actions are performed—for example, handling mouse movement, keyboard input, or window closing. This approach provides maximum flexibility but requires the developer to write numerous code lines and understand the event structure.

In practice, most game developers rely on cross-platform libraries or built-in input systems in game engines like Unity, Unreal Engine, or Godot. These solutions handle the low-level, messy interaction with the OS and expose a unified and user-friendly interface for processing keyboard, mouse, gamepad, and touch input. Here's an example:

while (engine.isRunning())
{
  Event event;

  while (engine.pollEvent(event))
  {
    switch (event.type)
    {
      case Event::MouseMove: 
        application.onMouseMove(event.mouseX, event.mouseY);
        break;

      case Event::KeyPressed:
        application.onKeyPressed(event.keyCode);
        break;

      case Event::WindowClose:
        engine.quit(); 
        break;
    }
  }

  engine.update(); // Game logic
  engine.render(); // Frame rendering
}

Another option is to integrate event handling directly into the engine and provide the user only with calls to handler functions. It accelerates and streamlines early development. However, it requires a well-designed architecture for registering these functions.

This approach makes life much easier for game developers, especially at the early stages of a project. Instead of manually querying input devices and processing complex event logic, developers simply register handlers for the events they're interested in—key presses, mouse movements, or screen touches.

The appropriate handlers are invoked at the right moment, with all the necessary event information about passed to them. This approach works well for simple games and prototypes, where rapid development is a priority and complex interaction logic isn't yet required. Popular libraries (frameworks) implement this event-driven model, but as a project grows in complexity, this architecture can become a source of problems. The main difficulty lies in creating a flexible system for registering and managing event handlers—callbacks must be easy to add and remove during execution, priorities may need to be set, and events may need to be filtered by game context. With many registered handlers, each event can trigger a chain of calls that were not initially anticipated. Here's an example of code:

void onMouseMove(MouseEvent event) {
  application.onMouseMove(event.mouseX, event.mouseY);
}

void onKeyPressed(KbEvent event) {
  application.onKeyPressed(event.keyCode);
}

void onWindowClose(AppCloseEvent ev) {
  engine.quit();
}

int main()
{
  engine.subscribe(onMouseMove);
  engine.subscribe(onKeyPressed);
  engine.subscribe(onWindowClose);

  while (engine.isRunning()) {
    Event event; updateFrame();
    engine.update(); // Game logic
    engine.render(); // Frame rendering
  }
}

Graphics

You got the main window and even teach your program to react on mouse and keyboard, but... You can't see its response—graphics comes to the stage. Honestly, I struggle with 3D graphics and am always jealous of my friend, @megai2, who can easily render everything for any platform, from consoles to mobile devices. Fortunately, most libraries for creating windows, like SDL, already provide support for 2D graphics. You can draw directly to the window, use textures, or even fill pixels with any colors. It's basic but honest.

Let's say the engine is optimized for 2D games built around tiles and sprites. Then, most likely, you'll have to implement something like drawSprite(image, x, y), possibly with support for all sorts of delightful features: scaling, rotation, blending, desaturation, and alpha blending. Internally, you can manually implement it either by directly copying pixels (with/without evaluations and blitting), or by relying on another library like Cairo. It turns out to be a very good renderer, capable of doing if not everything, then at least a great deal. You can also do it via OpenGL/DX/Vulkan, if your heart craves hardcore performance.

That's not the only option, you might also choose not to specialize at all and simply give the user a set of general-purpose APIs for the engine, as most SDL/SFML/Allegro libraries do—let them figure it out for themselves. In my implementation for the Pharaoh project, there is a wrapper over SDL (which supports native GAPI), but there is no full-fledged renderer in the usual sense. I wrote a new rendering system for each engine. On the one hand, it wasn't easy, but on the other, I had a chance to experiment with graphics to my heart's content.

No matter how the rendering system is built, sooner or later, you'll need to display text for the interface, debugging information, and other purposes. Yes, you can draw letters manually pixel by pixel, but it's better to use a standard library like FreeType. For eager fans of bizarre adventures and Unicode, HarfBuzz is worth exploring.

Resources

Once upon a time, you finalize another level, try to run the build, and... it takes about a whole minute to run. Then two. And then you notice that some stage "weighs" 2 GB, because each tree is an object with a unique copy of texture and models. That's when it becomes clear: it's time for resource management.

Resource management is hidden from users, but defines whether the game will be responsive and even run at all. First, it would be wise to pack resources into archives: opening a thousand files from a disk is a major drawback of OS interaction. The platform may be slow, the file system may not be very responsive, and the player's SSD might not match what you expected in the studio.

Therefore, everything gets packed: textures, models, sounds, levels, and scripts. Using a custom container format with indexing and compression is widespread, but some people use ready-made ones like Oodle, ZIP. Others create virtual file systems tailored to the engine's needs. Large commercial engines, by the way, usually follow this path. Archives are easy to distribute, easy to cache, and no one digs around... except the ones who really want to.

For example, you can compile all resources into one large binary blob and embed them into the executable file, as many games have done and continue to do. That's what Xbox and Sony did at first. What are the advantages? Everything is on hand and fast—no extra loadings, no paths to files—just grab a byte array and work with it as you would with a resource. In some projects, this approach quite literally saved releases and helped pass certification. Sure, that might leave you with a 700 MB binary file, but it's all because of the "my cat fell on the keyboard" moment and "the junior who wrote the templates crashed everything.".

Indeed, there are drawbacks: you can't change any asset without recompiling the entire game. Even if you just want to adjust a pixel color in a texture, you have to wait for a rebuild. It also makes modding virtually impossible: how would players add their funny custom hats if all content is "sealed" inside the .exe file?

You can store resources as regular files in the assets/ directory next to the executable file. Then the engine simply loads the necessary file when the level starts, if you haven't factored in performance. This is the best approach for development: it's fast, clear, and you can open the folder at any time, swap a texture, and see the changes in the game. And it's also a real gift for modders: they can just take it, tweak it, add to it—everything is open.

Regardless of how assets are stored, they still need to be converted from raw bytes into meaningful data. For this, you typically rely on format libraries—for example, stb_image to convert PNG to pixel arrays or various JSON libraries to extract information about entities from .json-like configuration files, if you haven't yet become disillusioned with JSON as a format for such files. At some point, the team realizes that a purely declarative configuration format is not enough, and then a VM (Virtual Machine) for JS/Lua/Squirrel/AngelScript is added to the engine. These are scripting languages, but in this context, they're used for parsing configurations.

In many projects, developers eventually move to custom formats or adopt a higher-level language, which, in practice, also leads to using a virtual machine or interpreter.

And you can—I would say you should—enable hot reloading of assets as a second step after the configurations, so that you don't have to restart the game a thousand times a day. You change the picture, sound, or configuration, and boom—they're right in your game. Pure magic? No, it's just another reason why the resource manager grows into a monster that affects the entire engine.

Resources aren't just a development concern—they also play a key role in the release process. The system must generate builds for different platforms: Windows, Linux, consoles, Steam Deck, and others. Each platform comes with its own constraints and requirements for data alignment, supported formats, and packaging rules. For example, some platforms do not allow MP3 files, while others do not support certain texture formats.

Finally, one of the trendiest and most important features is automatic updates and patches. The player must not have to download extra 10 GB if you changed one texture. My build system calculates deltas: which files have changed, how they can be compressed, and where to place them. The launcher checks versions and downloads only what is missing. And if something goes wrong, it can roll back. And honestly, players appreciate this more than almost anything else, when the game "updates itself and just works".

Audio output

In case you didn't know, audio output is a nightmare with platform-dependent APIs. They're ugly, unintuitive, and downright capricious; XBox has a habit of throwing exceptions if you write too much to the buffer, but... well, if you write less than the buffer's allocated size, it'll throw exceptions too. Audio output is just my hobby...I mean, I'm not an expert here, but even a little hands-on experience was enough to understand: if you just want to reproduce sound, get ready to suffer.

Or... you can just use a library that hides all this nightmare behind a clean interface, for example, OpenAL or SDL. Recently, I've been using the latter because it's very forgiving of mistakes, even if you blundered. These libraries usually expect the engine to provide the audio callback, a function that the system will call (usually from a separate thread) dozens or even hundreds of times per second.

Each call requires returning a small chunk of audio data. Maybe you just want silence. Maybe a single MP3 playing in the background. But most likely, you'll need a little more: music, effects, voice. Each in different streams, with different volume, with smooth fades, no clicks or pops, no tremors, add some reverb or other effects... well, you catch the point.

To ensure its stability, you need a mixer. Not a cooking machine, of course (though sometimes that wouldn't hurt), but an audio mixer—a library that will combine multiple audio streams into one, carefully control their volume, filter sharp peaks, apply effects, and prevent the sound from turning into a mess when a battle breaks out with 15 different unit sounds, fanfare, and alarming music.

A good engine usually implements its own audio mixer. It can be large and complex—with crossfading, reverb, effects, and post-processing—or it can be simple, with just a few channels and background music. But the idea is always the same: the mixer works with abstract sound streams, combines them, and produces a single output stream sent to the audio device.

Writing your own mixer at least once is a great way to understand how it works. Of course, you can also rely on existing libraries that already handle mixing, balancing, compression, and other audio processing tasks.

Physics

To be honest... most games don't actually need physics. I mean real physics—with forces, momentum, friction, and all that scientific stuff. Most people want something simpler: animations, logic, and scripts—things that look like physics without having much to do with it. For example, look at Civilization VI, one of the most complex strategy games of our time—the game has no need in physics implementation at all. Or take a peek at various city-building simulators (such as SimCity)—obviously, houses don't collapse, roads don't crack, and no one calculates the fall vector of a water tower because it's not necessary. So, why complicate things? Yet, somehow both Civ and Cities Skylines drag dependencies onto PhysX, maybe they actually use them, maybe not. Who knows.

Platformers or 2D RPGs don't need much physics too—it usually consists of character movement and simple collisions with walls, enemies, and boxes. You can write that in a couple of evenings, unless, of course, you get stuck on every line, as I did, trying to wrap my mind around it. The main thing is that everything will be under control: if you want the hero to slide like they're on ice, please do so. Enemies should bounce off when colliding like rubber ducks? Come on, give it a try.

If collisions start pilling up and performance drops, you can optimize it. Spatial hashing, quadtrees, and distance constraints from MC. But... if you're stubborn and know for sure that you need real physics, go for a ready-made library: Box2D for 2D or Bullet for 3D. Don't reinvent the wheel; you will have plenty of time to create them on the self-written engine.

And if you want to understand how such engines work under the hood, it's best to watch a YouTube video from the Box2D creator. He explains physics with impulses in a way that provides a rare insight into the mechanics. I used to think that physics was about mass, speed, and formulas, but now I know that real physics is when you're up at 3 a.m. trying to figure out why a character is stuck on a staircase because the collision mesh didn't load.

Author: Sergei Kushnirenko

Sergei has over 20-year experience in coding and game development. He graduated from ITMO National Research University and began his career developing software for naval simulators, navigation systems, and network solutions. For the past fifteen years, Sergei has specialized in game development: at Electronic Arts, he worked on optimizing The Sims and SimCity BuildIt, and at Gaijin Entertainment, Sergei headed up the porting of games to the Nintendo Switch and Apple TV platforms. Sergei actively participates in open-source projects, including the ImSpinner library and the Pharaoh (1999) game restoration project.

Webinar: Let's make a programming language. Intro— Key points

Unicorn Developer — Tue, 07 Apr 2026 11:48:38 +0000

We're happy to present the first part in a webinar series on creating your own programming language. If you've ever wondered what it takes to build your own language from scratch, this series is for you.

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 creating your own programming language, step by step.

Why would you want to create your own programming language?

You may ask us or our speaker, "What's the point? There are plenty of other languages!"

First of all, it's fun! Plus, if you want to enhance your programming skills and truly understand how your favorite language works, building a programming language can provide foundational knowledge of compiler internals and foster a deep appreciation for language design and implementation.

What's in the "black box"?

The webinar outlines the entire structure of a compiler or an interpreter, focusing on the "black box" that transforms human-readable source code into executable output or runtime results. Yuri briefly covers its core components:

lexer that divides the input into smaller parts—tokens—and tags them;
parser that operates on grammatic rules to understand the input and uses those tokens to build a syntax tree;
semantics that gives the syntax meaning and recognizes function names, data types, etc.;
evaluator that is a part of an optimization pipeline.

In the first session, Yuri introduces these concepts at a high level; future webinars will delve deeper into all aspects of the language under the expert guidance of our speaker. Everything will be explained step by step, so you can easily follow along.

Want more?

If you want to familirize with other webinars or see the whole webinar, follow this link.

You can also sign up for our upcoming webinars, for example: Let's make a programming language. Lexer. During the webinar, Yuri will walk you through how a lexer is actually implemented in code.

If you'd like to look closer what we do, check out our website.

We hope to see you there!

Webinar: Integrating SAST into DevSecOps — Key Points

Unicorn Developer — Mon, 06 Apr 2026 14:14:33 +0000

Today, we'd like to share with you our full video from the webinar 'Integrating SAST into DevSecOps'.

About speaker

Anton Tretyakov, an experienced DevOps engineer at PVS-Studio who builds and maintains the static analyzer infrastructure. He also writes about C++ in his spare time. During the webinar, Anton shares his insights on modernizing code security, seamlessly integrating static analysis tools into security workflows, and optimizing existing pipelines.

Key points

What is SAST?

Static application security testing (SAST) is a security check that automatically analyzes your code for errors and weak points without executing it. Unlike regular static analysis, a SAST tool detects potential vulnerabilities, not regular bugs.

Bugs vs Vulnerabilities

It's impossible to predict whether a bug will affect a program's behavior. A bug becomes a potential vulnerability when possible consequences of its presence in the source code are clearly defined. A potential vulnerability turns into a real one when it slips into real software and is exploited by a malicious user.

How does SAST work?

A SAST tool automates the tedious process of manually looking through every code line. To do this, it uses a syntax tree containing all the variables in a program. It scans the code for errors and issues a warning when it detects a flaw or potential undefined behavior that may harm the application.

How to integrate SAST into DevSecOps?

Early detection reduces the cost of fixing an error, so it is crucial to integrate a SAST tool into the development workflow as early as possible.

To check code, a SAST tool needs only a compilable project. Compared to other usual checks in a pipeline, static analysis provides comprehensive coverage of the whole program codebase. It works best when used together with other tests and checks.

Here's an example of how you can integrate static analysis into your pipeline:

build the project > pass credentials to the analyzer > run the analysis > get the analyzer report > extract metrics information from the report > export the metrics file to the Merge Request > move on to other development stages.

How to use SAST on legacy code

Static analysis detects various types of errors and can be used as the quality gate mechanism. When you work on a big project that also contains legacy code, you can see thousands of warnings issued by the analyzer. Sifting through them all is a really time-consuming and tedious task. This is where the one-direction approach comes into play.

Learn more: How to introduce a static code analyzer in a legacy project and not to discourage the team

How to use SAST as quality gate

PVS-Studio static analyzer allows running the analysis for the first time to save issued warnings in your database. Regularly check your project so that the tool can determine whether any changes have occurred. If the number of warnings increases, the changes to the repository are denied.

Learn more: Static analysis for pull requests. Another step towards regularity.

Want more?

That's only a part of the whole content that was covered during the session. If you want to learn more and see the whole webinar and look closer at slides, follow the link: Integrating SAST into DevSecOps.

You can also sign up for our upcoming webinars, for example: Let's make a programming language. Lexer. During the webinar, the speaker will walk you through how a lexer is actually implemented in code.

We hope to see you there!

Builds & Bugs: Which RPG class are you as a developer?

Unicorn Developer — Wed, 01 Apr 2026 14:38:10 +0000

Every developer's working days turn into routine sooner or later (even if everything feels inspiring and exciting to a freshly minted junior at first). Over time, the novelty wears off, confidence grows with seniority, and the next code review stops feeling like a thrilling challenge and becomes just another part of the workflow. Been there?

What if there was a different way to look at it? After all, "what is life but a game?" Seen that way, any project can become a real adventure. And every adventure needs brave heroes ready to fight bugs monsters. Turns out, you're one of them.

Whether you're into tabletop RPGs or digital ones, the classic archetypes are hard to miss: mages, warriors, rogues, and the rest. So, take a short break from the routine, answer a few questions, and try on the role of one of seven heroes. There's also something useful waiting at the end—a little help for your future battles with bugs.

How catch-block selection works in exception handling

Unicorn Developer — Tue, 31 Mar 2026 13:44:29 +0000

If a pill knows what to treat, could an exception also understand when to stop its journey through the stack? In application programming, a description like this is often enough, but sometimes one wants more details. Well, let's dive in!

Last time, we looked at how exceptions are thrown and caught, as well as the connection between these two processes. We've seen functions of the __cxa* and _Unwind* families, how they intertwine, and how the compiler embeds some of them into assembly code along with additional code blocks when compiling programs.

Some questions still remain unanswered. We've moved on from SjLj exceptions, and we've paused the discussion of zero-cost exceptions at the most thrilling point: the personality routine. In this article, we'll pick up right where we left off to answer the question, "How does an exception know it has reached the right catch block?"

Just like last time, we'll be using the libcxx library from LLVM. We'll also use the same compiler, Clang 21.1.0 for x86-64.

Previously...

While exploring the inner workings of the system, we came across two functions, _Unwind_RaiseException and _Unwind_ForcedUnwind, and thoroughly looked into how they work. The second function, which involved forced stack unwinding, was less exciting since it had no direct connection to our topic. However, the first one paved the way for understanding how exceptions are delivered through the program stack. It was executed in two stages: locating the appropriate catch block, and then delivering the exception along with calling automatic variable destructors.

While the stack traversal part is now clear, the process of determining the correct exception handler remains a mystery. All we know about how it works is that at some point during the execution of both stages, code like this executes:

_Unwind_Personality_Fn p = get_handler_function(&frameInfo); 
// ....
_Unwind_Reason_Code personalityResult =(*p)(
    1, action, exception_object->exception_class, 
    exception_object, (struct _Unwind_Context *)(cursor)
);

In the code, the frameInfo variable of the unw_proc_info_t type is used to retrieve handler, which is a function that determines when to stop stack unwinding. We can see that calling the p function returns some result. The calling stack unwinding driver uses this result to determine what to do next with the unwinding.

The frameInfo variable contains important information: a pointer to the handler itself and several other data members. They include pointers to the start and end of the function whose stack frame is being evaluated at the current stack unwinding stage, as well as other details.

In the previous article, we encountered the __gxx_personality_v0 symbol, which was defined in the assembly code that Clang generated from our test project. This symbol may be related to the handler, but we haven't proven it yet.

Let's revisit this project's code:

int bar()
{
    throw -1;
}

int foo()
{
    try {
        return bar();
    }
    catch (...) {
        return -1;
    }
}

int main()
{
    return foo();
}

We'll convert it to assembly code and work with that.

Assembly code:

bar():
        push    rbp
        mov     rbp, rsp
        mov     edi, 4
        call    __cxa_allocate_exception@PLT
        mov     rdi, rax
        mov     dword ptr [rdi], -1
        mov     rsi, qword ptr [rip + typeinfo for int@GOTPCREL]
        xor     eax, eax
        mov     edx, eax
        call    __cxa_throw@PLT

foo():
        push    rbp
        mov     rbp, rsp
        sub     rsp, 16
        call    bar()
        mov     dword ptr [rbp - 16], eax
        jmp     .LBB1_1
.LBB1_1:
        mov     eax, dword ptr [rbp - 16]
        add     rsp, 16
        pop     rbp
        ret
        mov     rcx, rax
        mov     eax, edx
        mov     qword ptr [rbp - 8], rcx
        mov     dword ptr [rbp - 12], eax
        mov     rdi, qword ptr [rbp - 8]
        call    __cxa_begin_catch@PLT
        mov     edi, 4
        call    __cxa_allocate_exception@PLT
        mov     rdi, rax
        mov     dword ptr [rdi], -1
        mov     rsi, qword ptr [rip + typeinfo for int@GOTPCREL]
        xor     eax, eax
        mov     edx, eax
        call    __cxa_throw@PLT
        jmp     .LBB1_8
        mov     rcx, rax
        mov     eax, edx
        mov     qword ptr [rbp - 8], rcx
        mov     dword ptr [rbp - 12], eax
        call    __cxa_end_catch@PLT
        jmp     .LBB1_5
.LBB1_5:
        jmp     .LBB1_6
.LBB1_6:
        mov     rdi, qword ptr [rbp - 8]
        call    _Unwind_Resume@PLT
        mov     rdi, rax
        call    __clang_call_terminate
.LBB1_8:

__clang_call_terminate:
        push    rbp
        mov     rbp, rsp
        call    __cxa_begin_catch@PLT
        call    std::terminate()@PLT

main:
        push    rbp
        mov     rbp, rsp
        sub     rsp, 16
        mov     dword ptr [rbp - 4], 0
        call    foo()
        add     rsp, 16
        pop     rbp
        ret

DW.ref.__gxx_personality_v0:
        .quad   __gxx_personality_v0

What if we just search for the __gxx_personality_v0 symbol in the libcxx library code? Well, we'll find it. Cool, thanks...

It's scary and confusing, but the most important thing is that we can't yet see a direct connection between this function and that handler. Well, let's try to determine it!

libunwind

We know one thing for certain: the handler is retrieved from a structure of the unw_proc_info_t type. It contains information about the function that created the current stack frame, as well as additional information needed to unwind the stack.

A super-quick introduction to libunwind

To trace the connection between the personality routine and this structure, we first need to understand where the structure gets populated. That means diving into the libunwind library. This library enables reading of function stack frames. We'll take a look at how its context initialization works under the hood, the data structure it uses to reference stack frames during unwinding, and how those structures are populated.

To move forward, let's go over the basics of working with libunwind. We can use the structure of the unw_cursor_t type to tell the library which frame we want to read. It's somewhat of a handler that enables us to traverse the stack. We get the frame information directly from the already familiar unw_proc_info_t structure. The cursor itself is retrieved from a context, which is a structure of the unw_context_t type. Once this structure is initialized, libunwind is ready to use.

The libunwind context

In our case, libunwind gets initialized in _Unwind_RaiseException, which we covered in the previous article. It serves as the entry point to the stack unwinding driver when an exception is thrown and is called almost immediately after it occurs. This happens within the abstraction layer defined by the the _cxa family of functions.

The libunwind initialization in this function looks like this:

  unw_context_t uc;
  unw_cursor_t cursor;
  __unw_getcontext(&uc);

There are two new types here: unw_context_t and unw_cursor_t. They have similar definitions: both contain data stored in arrays whose lengths are determined at compile time. It's impossible to say exactly what's stored there, since the data is located in a 64-bit unsigned integer array. This means that the types are opaque wrappers around other structures that are implementation details of the library. We can determine where the data is populated, though!

As we can see from the code of the _Unwind_RaiseException function, the unw_context_t struct is populated in the __unw_getcontext function.

Wow, we reached assembly code pretty quickly this time! It does fairly straightforward work—saving the register state into the unw_context_t structure, whose pointer we conveniently passed into the function beforehand. This function has platform-specific implementations that ensure the array within this struct is populated correctly.

Okay, a bunch of movq statements means that libunwind is initialized by saving the function register state where the operation begins. In our case, this is _Unwind_RaiseException, the main stack unwinding driver. This makes sense, since above this function frame are the frames of our program's functions where the exception was thrown.

Okay, where is the unw_cursor_t structure populated?

The libunwind cursor

The Unwind_RaiseException consists of two phases, which we covered in the previous article. Let's take a look at the beginning of the first phase:

static _Unwind_Reason_Code
unwind_phase1(unw_context_t *uc,
              unw_cursor_t *cursor,
              _Unwind_Exception *exception_object)
{
  __unw_init_local(cursor, uc);
  ....
}

We can see pointers to the context and the cursor being passed down from the _Unwind_RaiseException function. We can also see the __unw_init_local function, which receives those pointers. From this point on, things are about to get really interesting. This function determines the register type for the target platform. In reality, however, the compiler fixes this at compile time. Then, the function constructs a new UnwindCursor object using placement new inside the array stored in the unw_cursor_t struct.

// Use "placement new" to allocate UnwindCursor in the cursor buffer.
new (reinterpret_cast<UnwindCursor<LocalAddressSpace, REGISTER_KIND> *>(cursor))
    UnwindCursor<LocalAddressSpace, REGISTER_KIND>(
        context, LocalAddressSpace::sThisAddressSpace
    );

By the way, you might recall that we came across the UnwindCursor type in the previous article. We saw how it handles jumping to the correct point in the program via the jumpto function. That's why we'll take a closer look at it! In any case, its constructor is easy to find. The most interesting aspect is how it initializes the _registers member variable using a pointer to unw_context_t. The constructor is located nearby, and the type is defined in an earlier step.

Note that the cursor moves through different stack frames using the __unw_step function. This topic exceeds the scope of this article, so we'll leave it as homework for the most inquisitive minds.

Some info about the procedure in libunwind

Here's the code that kicked off our investigation today:

_Unwind_Personality_Fn p = get_handler_function(&frameInfo); 
// ....
_Unwind_Reason_Code personalityResult =(*p)(
    1, action, exception_object->exception_class, 
    exception_object, (struct _Unwind_Context *)(cursor)
);

Now that we know the cursor's origin, we can see where the frameInfo variable comes from.

In the code for both phases, we can see that this structure is populated by the __unw_get_proc_info function. It looks something like this:

unw_proc_info_t frameInfo;
if (__unw_get_proc_info(cursor, &frameInfo) != UNW_ESUCCESS)
{
  // ....
}

Inside __unw_get_proc_info, the pointer to unw_cursor_t is cast to the pointer to AbstractUnwindCursor, and then it calls the getInfo member function. We already saw how an instance of a specific UnwindCursor type is created inside the cursor. AbstractUnwindCursor is a virtual interface to objects of this class.

Inside the getInfo member function, the unw_proc_info_t instance stored within the cursor class is copied into the variable we're looking for. But wait... I can't recall seeing anything written to that internal member variable. Moreover, I remember it being directly zeroed in the constructor.

What did we miss?

The address of our precious handler can't be null. Besides, the address of some handler can't possibly appear in the registers. Let's face it, up until now, everything we've seen has been focused on preserving register states. I don't know about you, but I don't remember the System V ABI—or any other, for that matter—describing a separate register for some handler. So, that information is stored somewhere else.

Let's look into this some more and return to the __unw_init_local function. We deliberately omitted the call to the setInfoBasedOnIPRegister function there. Its name suggests that this might be exactly what we need. Perhaps the value of the data member in question is set there, among the many conditional compilation directives.

We have two options here: we can either figure out how binary files are parsed on GNU/Linux to find information for stack tracing, or we can just stop. Since this doesn't directly relate to the topic of this article, I think it's best to avoid getting bogged down in such details. Still, let's break down the general points, because that's exactly what makes table-based exceptions, well, table-based.

Summary N1

Why don't we make an interim summary?

Before moving down the stack, it's necessary to record the current processor state—the values of all its registers. To do this, we'll use unw_context_t. It's populated using the __unw_getcontext function, which is written in the assembly language. Its task is to simply copy the current register values into this structure.

The unw_cursor_t structure is used to navigate through stack frames. A cursor is an opaque pointer. In fact, it contains a hidden instance of the UnwindCursor class. The cursor is created using the context directly in the memory buffer of the unw_cursor_t structure.

The unw_proc_info_t structure is used to retrieve information about the function that created the stack frame we're interested in. The __unw_get_proc_info function populates the structure. It takes our cursor and pulls details about the current function from its internal data (the _info data member).

The key question is this: if the cursor constructor simply zeroes everything, where does it get function-specific data, such as the address of the exception handler (i.e., the personality routine)?

ELF, DWARF, and other xenos species

To get a better grasp of the issue, let's expand a bit the assembly code we obtained from our test example at the very beginning. Oh no, we won't be adding anything to the original C++ source code. Instead, we'll take a look at the complete version of this assembly code. It contains the code fragment directly related to our C++ source code, as well as various additional directives. I won't include the code in the article itself, as it's way too long. Let's look at some fragments below; the full code is available here.

The .cfi directives

The code has become much longer due to the additional metadata. We'll focus on the .cfi* family of directives that enable the debugger and profilers to traverse the stack, restore the frame state, and perform other tasks.

They don't execute code, but instead create unwind tables, also known as exception frames. The tables aren't in the assembly file; the compiler creates them in the final binary. You can view them using, for example, the readelf -w command.

Here's an example of running the 'readelf -w' main command:

$ readelf -w main
Contents of the .eh_frame section:

00000000 0000000000000014 00000000 CIE
  Version:               1
  Augmentation:          "zR"
  Code alignment factor: 1
  Data alignment factor: -8
  Return address column: 16
  Augmentation data:     1b
  DW_CFA_def_cfa: r7 (rsp) ofs 8
  DW_CFA_offset: r16 (rip) at cfa-8
  DW_CFA_nop
  DW_CFA_nop

00000018 0000000000000014 0000001c FDE cie=00000000
pc=00000000000010a0..00000000000010c6
  DW_CFA_advance_loc: 4 to 00000000000010a4
  DW_CFA_undefined: r16 (rip)
  DW_CFA_nop
  DW_CFA_nop
  DW_CFA_nop
  DW_CFA_nop

00000030 0000000000000024 00000034 FDE cie=00000000
pc=0000000000001020..0000000000001090
  DW_CFA_def_cfa_offset: 16
  DW_CFA_advance_loc: 6 to 0000000000001026
  DW_CFA_def_cfa_offset: 24
  DW_CFA_advance_loc: 10 to 0000000000001030
  DW_CFA_def_cfa_expression ; ...
  DW_CFA_nop
  DW_CFA_nop
  DW_CFA_nop
  DW_CFA_nop

They allow the stack unwinder to restore stack frame states using only the instruction pointer value. It looks suspiciously similar to the debugger information in debug builds, because that's exactly what it is. The debugger does pretty much the same thing. The table format is defined in the DWARF standard, which is why the exception-handling approach discussed here is sometimes referred to as DWARF-based.

These directives are all necessary for a program, such as a debugger, to retrieve information about the currently examined stack frame. This topic is beyond the scope of this article. There are three ways to learn more: read a brief note about the format of these tables and leave it at that, check out this excellent introductory article on the topic, or dig into the DWARF documentation (if you're a true rock and roller).

However, we're interested in a few specific aspects. Take a look at the foo function prologue (the one that catches the exception in our example):

foo():
.Lfunc_begin1:
        .loc    1 7 0
        .cfi_startproc
        .cfi_personality 155, DW.ref.__gxx_personality_v0
        .cfi_lsda 27, .Lexception0

Two directives deserve particular attention: .cfi_personality and .cfi_lsda.

Since we're working with LLVM, let's consult their documentation. There's some interesting content, including a link to other documentation that specifically describes the .cfi directives we need. As the description states, the .cfi_personality directive specifies where the stack unwinder retrieves the personality routine. Note that in our code, this instruction contains the DW.ref.__gxx_personality_v0 symbol. The origin of this symbol has remained a mystery to us since the first article.

Take a look at the code at the very bottom of the assembly file:

DW.ref.__gxx_personality_v0:
        .quad   __gxx_personality_v0
        .ident  "clang version 21.1.0
        .section        ".note.GNU-stack","",@progbits
        .addrsig
        .addrsig_sym bar()
        .addrsig_sym __cxa_allocate_exception
        .addrsig_sym __cxa_throw
        .addrsig_sym foo()
        .addrsig_sym __gxx_personality_v0
        .addrsig_sym __cxa_begin_catch
        .addrsig_sym __cxa_end_catch
        .addrsig_sym __clang_call_terminate
        .addrsig_sym _ZSt9terminatev
        .addrsig_sym _Unwind_Resume
        .addrsig_sym _ZTIi
        .section        .debug_line,"",@progbits

The address of the __gxx_personality_v0 function is stored in memory. Next comes a section containing symbols that we've already encountered.

The directive in .cfi_lsda specifies the location of the language-specific data area. What's this? Now look at the symbol located near the end of the foo function:

GCC_except_table1:
.Lexception0:
        .byte   255
        .byte   155
        .uleb128 .Lttbase0-.Lttbaseref0
.Lttbaseref0:
        .byte   1
        .uleb128 .Lcst_end0-.Lcst_begin0
; ...

Good news—we've finally found this thing called exception handling tables. More precisely, this is the language-specific data area (lsda), which contains the exception handling tables. There are several of these tables, and we'll take a look at them a little later.

Okay, we still don't know exactly how the personality routine and lsda work, but at least we've found where their symbols are defined. In the case of lsda, we also found its exact location.

Reading binaries

The way these two components—the personality-routines and lsda—work is simple: the first looks to the second to determine what to do with the exception in each stack frame it encounters. We'll see how it works a little later. For now, let's make sure that the C++ runtime actually reads addresses of the personality routines and lsda. To do this, we'll go back to the breakdown of the setInfoBasedOnIPRegister function.

The code contained many conditional compilation directives depending on the runtime's stack unwinding technique. Since we now know that the method in question is DWARF-based, we can locate the relevant parts of this function. There are two of them: one and two.

Let's stop here— describing how to read DWARF structures would make this article endless. The resources listed above should give you a general idea of the topic. Long story short, it all comes down to the getInfoFromFdeCie function. It actually populates the _info data member using information obtained from the unwind tables, including the addresses of the personality routine and lsda.

Summary N2

It seems like now's the time for a little summary.

The compiler inserts special directives that begin with .cfi_ (Call Frame Information) when converting C++ code into assembly. The processor doesn't actually execute these directives—they instruct the linker to build unwinding tables from this data.

We've already seen a few of them:

.cfi_personality specifies the address of the exception handler (the personality routine) for the function;
.cfi_lsda points to the Language Specific Data Area (LSDA)—function-specific metadata that tells the runtime how to handle an exception when it processes a particular stack frame.

After compilation, all .cfi directives are converted into binary structures, which we can view using the readelf -w command. They contain .eh_frame entries with general information on how to unwind the stack for each function.

How exactly does the personality routine read the lsda, though?

The personality routine, lsda, and two types of unwinding

The challenge with the personality routine is that it performs many similar actions in similar scenarios that still need to be distinguished from one another. Combine this with various ways to unwind the stack and exceptions that might occur in other languages, and the result is a Frankenstein's monster. Still, all these parts serve the same goal, and that's where we'll start.

The personality routine parses the lsda to determine how to handle the exception within the context of a specific stack frame. In other words, it must know how to parse the stack in order to retrieve from memory the data contained in the lsda. Although this routine involves low-level work, it's conceptually quite high up in the Itanium ABI, at a level that defines language-specific functionality.

In the previous article, we looked at an interface from the _cxa* family responsible for exception allocation, throwing, and catching. This behavior applies only to the C++ language and isn't related to stack unwinding, which conceptually operates at a lower level. The personality routine is on the same level as the _cxa* family, and it acts as a callback invoked by other subsystems during stack unwinding.

There are two unwinding contexts where the personality routine is called: an exception throw and something else. The first one is initiated in the _Unwind_RaiseException and _Unwind_SjLj_RaiseException functions, while _Unwind_ForcedUnwind is responsible for everything else (such as unwinding the stack when exiting a thread). An exception throw consists of two stages: finding the appropriate catch block and cleaning up the stack. We covered all of this in the previous article.

The _Unwind_Action defines the specific context. It shows that during the second phase of exception handling, the routine can do one of two things: either clean up the current frame or transfer control to a catch block identified during the first phase. It also includes a separate case for reaching the end of the stack during unwinding without an exception.

The personality routine algorithm

Okay, let's take a look at the code of this routine. We'll skip the details of parsing the lsda for now and try to grasp the general logic. For the sake of simplicity, we'll remove the conditional compilation that isn't relevant to our stack unwinding approach or platform.

The simplest case occurs when, during the second phase, we reach the same frame that we marked in the first phase as having a valid catch block.

if (actions == (_UA_CLEANUP_PHASE | _UA_HANDLER_FRAME) &&
    native_exception) {
    // Reload the results from the phase 1 cache.
    __cxa_exception* exception_header =
        (__cxa_exception*)(unwind_exception + 1) - 1;
    results.ttypeIndex = exception_header->handlerSwitchValue;
    results.actionRecord = exception_header->actionRecord;
    results.languageSpecificData = exception_header->languageSpecificData;
    set_landing_pad(results, exception_header->catchTemp);
    results.adjustedPtr = exception_header->adjustedPtr;
    set_registers(unwind_exception, context, results);
    if (results.ttypeIndex < 0) {
      exception_header->catchTemp = 0;
    }
    return _URC_INSTALL_CONTEXT;
}

At this point, the routine retrieves the information it gathered during the previous phase and returns the _URC_INSTALL_CONTEXT value. This tells unwind_phase2 that it's time to move to the catch block. The exact landing point comes from the cursor state passed when calling the routine and set in the set_registers function.

In all other cases, that is, if we haven't reached the end of the exception throw's second phase, we need to parse the lsda to determine the next step:

scan_eh_tab(results, actions, native_exception, unwind_exception, context);

The following code is a bit unintuitive:

if (results.reason == _URC_CONTINUE_UNWIND ||
    results.reason == _URC_FATAL_PHASE1_ERROR)
    return results.reason;

if (actions & _UA_SEARCH_PHASE)
{
    assert(results.reason == _URC_HANDLER_FOUND);
    if (native_exception) {
        __cxa_exception* exc = (__cxa_exception*)(unwind_exception + 1) - 1;
        exc->handlerSwitchValue = static_cast<int>(results.ttypeIndex);
        exc->actionRecord = results.actionRecord;
        exc->languageSpecificData = results.languageSpecificData;
        get_landing_pad(exc->catchTemp, results);
        exc->adjustedPtr = results.adjustedPtr;
    }
    return _URC_HANDLER_FOUND;
}

_URC_CONTINUE_UNWIND can be set in either the first or second phase. The first one is clear: a handler hasn't been found at that point. In the second phase, this value is set if the stack in question contains neither catch blocks nor automatic variables whose destructors should be called when unwinding the stack.

_URC_FATAL_PHASE1_ERROR is set when the parser finds something in lsda that shouldn't be there. This indicates an error.

Otherwise, there's only one thing left to do in the first phase—celebrate finding the right handler! For native C++ exceptions, we store the relevant information for later (we saw it being used toward the end of the second phase earlier). For foreign exceptions, we simply report finding the handler. In both cases, the routine returns _URC_HANDLER_FOUND.

At this point, only one option remains: we're in the second phase and need to perform some action in the current stack frame:

assert(actions & _UA_CLEANUP_PHASE);
assert(results.reason == _URC_HANDLER_FOUND);

What can it be? Given that we'd enter the valid catch block right at the beginning of the function, we have two options: to either call stack variable destructors, or handle exception specifications:

set_registers(unwind_exception, context, results);
if (results.ttypeIndex < 0) {
  __cxa_exception* exception_header =
        (__cxa_exception*)(unwind_exception + 1) - 1;
  exception_header->catchTemp = 0;
}
return _URC_INSTALL_CONTEXT;

The last line is all we need here. The _URC_INSTALL_CONTEXT value instructs the runtime to transfer control to the code fragment the routine found. This is a landing pad, which is a block of code that either handles an exception or an exception specification, or it calls destructors.

The lsda structure

The lsda is parsed in LLVM within the scan_eh_tab function. Analyzing how it works would be interesting, but instead, explaining what exactly this lsda contains—with varying degrees of clarity—seems more useful.

As we previously learned, the lsda includes exception handling tables. The name kind of hints that there are multiple of those. The specification does confirm this.

The first one is called the call sites table. It's a list of entries containing pointers to the start and end of an instruction sequence containing the instruction from which the exception was thrown. With the address of this instruction (the unwinder restores it from the DWARF tables we discussed above), we can understand which entry to use. The call site itself is a code snippet located either inside or outside the try block. It's kind of a critical section where specific actions happen during stack unwinding. The list of possible actions follows the call sites table, and the required action is identified by an index that is stored alongside pointers to the start and end of a specific call site.

Right after the call site table comes the action table, which is a list of actions associated with a particular call site. Although it's called a "table," it's actually a linked list. In addition to a pointer to the next node, each element contains a type index, which is a multipurpose data member of an integer type. If it's zero, then destructors are called in the current stack frame. Control must be passed to the code that contains calls generated by the compiler. If it's greater than zero, then we're dealing with the catch block, and it's necessary to check whether the catch block type matches the exception type. In this case, the number acts as an index to a table of types supported by the catch blocks of this frame (that table follows the current one). If the index is negative, then we're dealing with an exception specification, and it's necessary to determine whether the function can throw an exception of that type.

Following the action table is the type table, which contains references to the std::type_info objects for the types supported by the catch blocks of the current frame. This table is indexed by the positive indices contained in the nodes of the action table linked list.

Somewhere nearby—depending on the implementation—is a list of references to the std::type_info types listed in the exception specification. If you're using older standards that allow such specifications, this is where the runtime handles unsupported types. In this case, the handler logic works in reverse: __cxa_call_unexpected is called when an exception lands in the generated code after violating the specification. That function ultimately behaves similarly to the deprecated std::unexpected.

The structure of this mess looks something like this:

========================
Lsda header
LPStart Encoding
LPStart (optional)
TType Encoding
TType Offset (optional)
Call-Site Encoding
Call-Site Table Length
========================
Call-Site Table
------------------------
start of a call site
length of a call site
landingPad (handler) offset (from landingPad base)
actionEntry (1-based offset)
------------------------
------------------------
start of a call site
length of a call site
landingPad (handler) offset (from landingPad base)
actionEntry (1-based offset)
------------------------
========================
Action Table
------------------------
ttypeIndex = 3
nextOffset = -3 
------------------------
------------------------
ttypeIndex = 2
nextOffset = -3 
------------------------
------------------------
ttypeIndex = 1
nextOffset = 0
------------------------
========================
Type Table (RTTI)
------------------------
index 1 ──> typeinfo(float)
------------------------
------------------------
index 2 ──> typeinfo(int)
------------------------
------------------------
index 3 ──> typeinfo(T)
------------------------
========================

Summary N3

That's the way the ball bounces. Let's summarize!

The personality routine can parse the lsda. The lsda contains language-specific information about what should happen in a given stack frame when an exception is thrown. The lsda is generated by the compiler and appended to the function body.

The personality routine is called from the _Unwind* family of functions, which are stack unwinding drivers. These functions form a layer independent of any programming language. In other words, a routine is a callback that logically belongs to a language-specific layer.

We also learned about the "landing pad" concept. This is essentially a generalization over the catch block, which can handle exception specifications and destructor calls in addition to the exceptions.

So, how does this landing pad actually work?

The last mile and landing pad

We've slightly modified the code for clarity:

#include <stdlib.h>

int bar() throw (int)
{
    return (rand() % 2) ? throw -1 : -666;
}

int foo()
{
    try {
        return bar();
    }
    catch(float) {
        return 69;
    }
    catch(int) {
        return 42;
    }
    catch (...) {
        //skiped intentionally
    }
    return 666;
}

int main()
{
    return foo();
}

The assembly code is below. The link leads to the same file, but it has additional compiler directives.

Assembly code:

bar():
        push    rbp
        mov     rbp, rsp
        sub     rsp, 32
        call    rand@PLT
        mov     ecx, 2
        cdq
        idiv    ecx
        mov     byte ptr [rbp - 9], 0
        cmp     edx, 0
        je      .LBB0_2
        mov     edi, 4
        call    __cxa_allocate_exception@PLT
        mov     rdi, rax
        mov     qword ptr [rbp - 8], rdi
        mov     byte ptr [rbp - 9], 1
        mov     dword ptr [rdi], -1
        mov     rsi, qword ptr [rip + typeinfo for int@GOTPCREL]
        xor     eax, eax
        mov     edx, eax
        call    __cxa_throw@PLT
        jmp     .LBB0_8
.LBB0_2:
        jmp     .LBB0_3
.LBB0_3:
        mov     eax, 4294966630
        add     rsp, 32
        pop     rbp
        ret
        mov     rcx, rax
        mov     eax, edx
        mov     qword ptr [rbp - 24], rcx
        mov     dword ptr [rbp - 28], eax
        cmp     dword ptr [rbp - 28], 0
        jge     .LBB0_7
        mov     rdi, qword ptr [rbp - 24]
        call    __cxa_call_unexpected@PLT
.LBB0_7:
        mov     rdi, qword ptr [rbp - 24]
        call    _Unwind_Resume@PLT
.LBB0_8:

foo():
        push    rbp
        mov     rbp, rsp
        sub     rsp, 48
        call    bar()
        mov     dword ptr [rbp - 32], eax
        jmp     .LBB1_1
.LBB1_1:
        mov     eax, dword ptr [rbp - 32]
        mov     dword ptr [rbp - 4], eax
        jmp     .LBB1_9
        mov     rcx, rax
        mov     eax, edx
        mov     qword ptr [rbp - 16], rcx
        mov     dword ptr [rbp - 20], eax
        mov     eax, dword ptr [rbp - 20]
        mov     dword ptr [rbp - 36], eax
        mov     ecx, 3
        cmp     eax, ecx
        jne     .LBB1_5
        mov     rdi, qword ptr [rbp - 16]
        call    __cxa_begin_catch@PLT
        movss   xmm0, dword ptr [rax]
        movss   dword ptr [rbp - 28], xmm0
        mov     dword ptr [rbp - 4], 69
        call    __cxa_end_catch@PLT
        jmp     .LBB1_9
.LBB1_5:
        mov     eax, dword ptr [rbp - 36]
        mov     ecx, 2
        cmp     eax, ecx
        jne     .LBB1_7
        mov     rdi, qword ptr [rbp - 16]
        call    __cxa_begin_catch@PLT
        mov     eax, dword ptr [rax]
        mov     dword ptr [rbp - 24], eax
        mov     dword ptr [rbp - 4], 42
        call    __cxa_end_catch@PLT
        jmp     .LBB1_9
.LBB1_7:
        mov     rdi, qword ptr [rbp - 16]
        call    __cxa_begin_catch@PLT
        call    __cxa_end_catch@PLT
        mov     dword ptr [rbp - 4], 666
.LBB1_9:
        mov     eax, dword ptr [rbp - 4]
        add     rsp, 48
        pop     rbp
        ret

main:
        push    rbp
        mov     rbp, rsp
        sub     rsp, 16
        mov     dword ptr [rbp - 4], 0
        call    foo()
        add     rsp, 16
        pop     rbp
        ret

DW.ref.__gxx_personality_v0:
        .quad   __gxx_personality_v0

First, let's look at this little example with the bar function:

.LBB0_3:
        mov     eax, 4294966630
        add     rsp, 32
        pop     rbp
        ret
        mov     rcx, rax
        mov     eax, edx
        mov     qword ptr [rbp - 24], rcx
        mov     dword ptr [rbp - 28], eax
        cmp     dword ptr [rbp - 28], 0
        jge     .LBB0_7
        mov     rdi, qword ptr [rbp - 24]
        call    __cxa_call_unexpected@PLT

It's interesting because it shows how exception specifications are handled. If the function throws an exception of a type not listed in its specification, the personality routine will read the lsda and instruct the unwinder to transfer control to this point. Calling __cxa_call_unexpected is usually something that your program won't survive.

Another interesting detail is in the foo function. It handles the selection of the specific catch block that processes the exception. The lsda provides the runtime with a pointer to a landing pad. However, that landing pad represents a handler in general rather than a specific one. With catch blocks, it points to the start of the entire catch block section that follows a given try block, rather than to a specific handler.

Let's take, for example, an exception handler for the int type:

.LBB1_5:
        mov     eax, dword ptr [rbp - 36]
        mov     ecx, 2
        cmp     eax, ecx
        jne     .LBB1_7
        mov     rdi, qword ptr [rbp - 16]
        call    __cxa_begin_catch@PLT
        mov     eax, dword ptr [rax]
        mov     dword ptr [rbp - 24], eax
        mov     dword ptr [rbp - 4], 42
        call    __cxa_end_catch@PLT
        jmp     .LBB1_9
; ...
.LBB1_9:
        mov     eax, dword ptr [rbp - 4]
        add     rsp, 48
        pop     rbp
        ret

In addition to the usual things like calling __cxa_begin_catch and __cxa_end_catch, we can see some code that looks strange at first glance:

        mov     eax, dword ptr [rbp - 36]
        mov     ecx, 2
        cmp     eax, ecx
        jne     .LBB1_7

In this fragment, a conditional jump occurs if something isn't equal to 2. 2 of what? Why not 3?

Think back to how we discussed tables within the lsda earlier. It contained a type table indexed by numbers found in entries of the action table. In this assembly code, 2 is an index that the runtime kindly stored in the __cxa_exception structure of the thrown exception when calling the personality routine. If the program had thrown a different exception type that still matched one of the available catch blocks, the runtime would've stored a different index to identify the correct type.

That's it—it wasn't so bad after all! There isn't much to summarize here since this part doesn't introduce many new concepts.

Is this the end?

Dear friends, if you're reading this, I want you to know that you're real heroes, and I admire you. Getting through all of this wasn't easy. I hope it was worth the effort, and you learned something cool—or at least something new—along the way!

One question remains unanswered: how do exceptions over the setjmp/ longjmp mechanism work? That's a great reason to revisit the topic in the future!

I'd love to read your thoughts in the comments—hope to see you there!

El Psy Kongroo.

"Please press button for assistance"

Unicorn Developer — Tue, 31 Mar 2026 06:28:00 +0000

Back when I joined PVS-Studio five years ago, my ex-colleague (who pretty much taught me how to code) wrote an article on tech support and how to avoid burning out. Over the past few years, our support team has gone through significant changes, so it's time to update things.

I'm a customer support manager, so that's partly my job—and today I'll tell you about how we do things. Next, I'll show how the support team is currently working in PVS-Studio. Wishing you all the best and lots of positive vibes. But remember: if something goes wrong, please click here for assistance...

Service structure

I've been in PVS-Studio tech support for four years now. Back when I started, our developers handled all technical support themselves, but today, our support service has grown like a snowball honestly, I wouldn't mind being under that snowball myself.

Over the years, we've gradually enhanced the quality of the support service and automated certain aspects of it. Now we have much greater control over our service operations and our own staff. Now I'll explain how developing in-house tools and making the most of our support team's experience has helped us raise the quality bar.

The old model, where only developers provided support to users, worked as long as the workload wasn't too high. But the analyzer is growing, diagnostic rules are being developed, and integrations are being added. Even in the old, slightly simpler mode, it wasn't very handy. As the analyzer continued to evolve, there was a need to expand and automate the support pipeline.

You can see the difference between how things used to be and what we've managed to put together so far in the tables below. Tsss... It's a little secret, but you'll get a sneak peek into how we work behind the scenes :)

Look at support departments:

Previously (pre-2021)

Sales: handles the evaluation period and initial non-technical support without getting into technical details, and handles partnership requests.
Development departments: handles all technical requests.

Currently (since 2024)

Sales: handles partnership opportunities.
SalesDev: handles evaluation period and first-line support.
Technical Support: handles technical requests.
Development departments: handles specific technical requests.

I work in the SalesDev department and provide assistance when customers evaluate our tools. Plus, I handle the first-line support for resolving simple technical and advisory requests. If you're one of our clients, we might have even exchanged emails :) I also lead a project to expand our support services. We develop new tools, document processes, analyze technical support statistics, and identify areas for improvement.

Looking at the numbers, splitting responsibilities across departments has been very helpful in distributing the workload across our development teams. The technical support department was established in late 2024, and in 2025, they already sent 1,119 emails.

On top of my main duties, over the past four years my manager, colleagues from the technical departments, and I have rolled out a bunch of tech support projects, which you can see in the table listing the tools we've implemented along the way.

The tools we use for support:

Previously (pre-2021)

Scenario flowcharts.
Team stats, ticket handling time, etc.
A third-party helpdesk where it was difficult to implement internal customizations.

Currently (since 2024)

Our in-house helpdesk, where we can customize as we want (header, message body, email editing, comments, email threads, etc.)
Communication tags: managerial, technical, etc.
Technical closure statuses for conversations.
Defined processes and areas of responsibility.
Technical solutions database for the analyzer.
Checklists for clarifying environments in specific cases.
Updating the feedback page with templates based on the request.
Scenario flowcharts.
Built-in templates that employees create themselves.
Team stats, ticket handling time, etc.
Statistics on recurring patterns in conversations.

This is the part I can actually show—the tools that make our support tick. Of course, people come first, but the numbers speak for themselves.

For 2025, the the median ticket resolution time dropped by six days (from 19 to 13) and reduced our response time almost threefold. The current average response time is around 9 hours.

Wishing everyone all the best, smooth processes, and lots of love—and once again, if something goes wrong, please press here for assistance...

Conclusion

Over the past five years, support for PVS-Studio has undergone many changes. All of this is for the benefit of our clients and employees. We've implemented some really useful tools, and now we're better able to understand users' needs and challenges, analyze our mistakes, and handle technical support requests. Our human resources are organized more effectively, with new departments each responsible for their own area of support and service.

Support matters. In many cases, it's a key factor in whether a customer decides to use the tool regularly or purchase a license.

This work has yielded significant results, as evidenced by our internal statistics. That's why support is awesome. And of course, we welcome your feedback!

Wishing everyone peace, love, great articles, and successful projects—and once again (last time, I swear), if something goes wrong, please press here for assistance...

Get started with PVS-Studio static analyzer

Unicorn Developer — Fri, 27 Mar 2026 14:04:48 +0000

PVS-Studio static analyzer is a tool for detecting code errors throughout the entire project lifecycle. In this article, you can meet the key analyzer features, common usage scenarios, and analysis options, and learn everything you need to get started.

What is PVS-Studio?

PVS-Studio is a SAST tool that identifies potential errors and vulnerabilities in the source code of C, C++, C#, and Java projects. It's a B2B solution trusted by many development teams and companies around the world.

The analyzer runs on Windows, Linux, and macOS, offering several usage and integration scenarios with various tools.

Usage scenarios of static analysis

PVS-Studio offers multiple ways to integrate static analysis into your workflow. It can be arranged as an IDE plugin, as well as an automated server testing tool. You can choose the approach that fits your workflow best—or combine all options to fully protect your code by integrating the analyzer at every developing stage.

On-premise analysis

One of the practical ways to use the analyzer is to run it locally on developers' machines, either via the IDE plugin or the console version.

This is also the most versatile approach, covering a wide range of environments:

Windows, Linux, and macOS
platform-independent launching methods
IDEs
build systems
game engines (PVS-Studio can analyze game projects).

This scenario allows developers to catch errors early and efficiently, right as the team is working on a new functionality or refining an existing one, enabling make quick code changes.

However, it's worth combining multiple options to supply your pipeline with advanced security. For example, to prevent defects from entering version control systems (VCS), it'd be better to have a second-level protection: regular static analysis on the build server.

Regular static analysis

The best approach is to implement a two-level source code verification system both on premise and on server. The earlier an issue is detected, the lower the cost and complexity of fixing it. We would also recommend using incremental analysis to automatically analyze only modified code after a build. This enables optimize and enhance performance the CI pipeline.

Regular analysis for pull requests significantly streamlines the code review process. Even if errors get into VCS, they can be quickly spotted and fixed, potentially saving time, money, and the product's reputation.

Early detection is one of the key static analysis benefits along its regular usage. Running analysis only once, for example, before a release, can lead to several problems:

Increased time required to review and mark up warnings
Reduced analysis quality (the more warnings reviewed at once, the easier it's to miss important issues)
More complex bug fixing (long periods between introducing and detecting an issue can force developers to spend time to familiarize with the context)

For more details about the regular use of PVS-Studio, CI integration, and configuration recommendations, please refer to this documentation.

In addition to on-premise infrastructure, you can always configure analysis in cloud-based CI services. PVS-Studio integrates with most of the prominent cloud-based CI systems. You can find the complete list and setup instructions on this page.

Note. PVS-Studio can analyze commits and branch merging (pull/merge requests). In this mode, only files modified relative to the current branch state are analyzed. This reduces analysis time and facilitates result review. More details are provided in the documentation.

Server-side analysis

Project analysis can be integrated into nightly builds to generate a detailed report on the codebase state each day. Regular analyzer feedback on detected issues can help quickly fix the problematic code.

A key scenario characteristic is that the analyzer operates with the full project context. This increases effectiveness through intermodular analysis and detects issues in different program components.

For example, a potential defect may be located in one file (e.g., a missing null check) while its consequences appear in another program segment (e.g., a NullReferenceException occurs when the object is accessed).

To further improve efficiency, analysis results can be integrated with code quality management tools (web dashboards). These tools enhance interaction with reports without requiring changes to the existing development pipeline and provide additional capabilities such as analysis result visualization, report aggregation, issue tracking and resolution management, etc.

The full list of supported tools and integration instructions is available in the documentation.

Supported standards

PVS-Studio is a SAST (Static Application Security Testing) solution that searches for security defects and helps refine overall code security.

Code reliability

Code reliability is critical in industries where software defects can have severe consequences, such as aerospace, medical, and engineering. Errors in applications with high-reliability requirements can lead to millions of dollars in losses or even endanger human lives.

To write reliable code, developers adhere to special coding standards, such as MISRA C, MISRA C++, and AUTOSAR Coding Guidelines.

PVS-Studio identifies the code that doesn't comply with these standards. To see the full list of diagnostic rules mapped for the standards, please refer to the following documentation:

Code security

Secure code is more resilient to various types of cyberattacks, such as SQL injections, XEE, XXE, and others. Thus, code security is especially critical in applications that handle user-sensitive data (banking software, web applications, etc.).

To ensure applications are secure, development teams implement a secure software development lifecycle (SSDLC). One of its stages is to search for security issues using SAST (Static Application Security Testing).

Specialized standards are used to ensure secure code development. PVS-Studio maps its diagnostic rules to industry-recognized security standards and vulnerability lists (CWE), including:

Among all security flaws, the most dangerous and common ones are highlighted. Discover how PVS-Studio helps mitigate these risks:

Choosing a PVS-Studio license

Before getting started, we recommend reviewing the available PVS-Studio license options and choosing the one that best fits your team.

PVS-Studio is primarily tool for development teams, so we do not provide single-user licenses. Licenses are packaged according to the number of users in the team, but our flexible licensing policy makes it easy to adopt and manage the tool. Here are the main particularities:

The license is calculated based on the number of people in the team who leverage the repositories (that will be analyzed), rather than the number of machines involved.
One license can cover developers across several departments/projects.
There are no restrictions on code volume, diagnostic rules, and new versions.
Technical support comes directly from the analyzer developers.

Two main types of licenses

Team: suitable for small teams up to nine users. It includes basic analyzer features.
Enterprise: a good option for large teams. It has more features, more usage scenarios, and priority technical support.

Team license

The Team license is designed for small teams of up to nine developers (inclusive).

It includes basic support:

assistance with integrating into the development process;
prompt resolution of analyzer issues;
several analyzer developers simultaneously assisting in a single technical support request.

The license includes all core analyzer functionality but has some functional limitations related to development process quality management, such as:

automatic notifications
integration with cloud services
partial restrictions on incremental analysis
etc.

Note. For more details on what each PVS-Studio license includes, please refer to this page.

Enterprise license

The Enterprise license is designed for medium and large teams and has no restrictions on the use of the analyzer's functionalities. A single Enterprise license can be used by multiple teams within a company, including several small teams.

It includes all the basic analyzer functionality and additional features specific to this licensing option. These include:

adaptation of PVS-Studio functionality to the specifics of the customers' ecosystem;
several analyzer developers simultaneously assisting in multiple technical support requests;
analysis of files changed since the previous build;
on-premise and CI-driven usage of incremental analysis.

You can request a trial Enterprise license here.

Quick start

Relevant analyzer warnings

If you're new to static analysis tools and want to explore their functionality, you can use the Best Warnings mechanism that is designed specifically for the first encounter with PVS-Studio static analyzer.

It highlights the most important and reliable warnings in the project report. To display them, click the Best button:

The report displays ten warnings, giving a quick overview of the analyzer's potential without reviewing the entire list of results.

How to work with legacy code using static analysis

PVS-Studio has a mass suppression mechanism intended for use when integrating the analyzer into an existing codebase with a large number of pre-existing warnings.

Mass suppression mechanism helps focus on analyzing new code while preserving the ability to return to warnings found in legacy code later.

As a result, the report will include only warnings related to newly written or modified code. This mode doesn't require any changes to the project's source files.

For more details, you can refer to the documentation.

What's next?

If you still haven't tried the analyzer on your project, feel free to evaluate its performance. You can obtain a trial license here.

To learn more, you can read a full version of the documentation.

If you have further questions about configuring the analyzer or understanding its behavior, you can leave a comment below the article or contact us via the feedback form.