DEV Community: Unicorn Developer

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

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

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

About the speaker

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

Parsing and name resolution

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

Types and implicit conversions

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

Building the syntax tree

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

Want more?

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

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

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

See ya!

Static and dynamic analysis help when unit tests fail

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

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

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

String concatenation bug

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

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

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

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

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

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

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

Granularity

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

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

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

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

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

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

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

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

Limitations of unit tests

We can write unit tests like these:

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

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

And still miss the issue. The tests pass successfully:

a+=a ok
12+345=12345 ok

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

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

More unit tests

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

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

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

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

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

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

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

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

Early error detection

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

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

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

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

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

Conclusion

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

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

Webinar on common mistakes Go developers make

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

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

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

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

What we'll cover

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

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

Join us live

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

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

How PVS-Studio helps enhance quality of embedded projects

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

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

Features of embedded systems

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

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

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

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

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

Specialized analysis mechanisms

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

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

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

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

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

Compilation monitoring CLMonitor.exe (for Windows)

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

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

How to start compilation monitoring

To start the monitoring process, run the following command:

CLMonitor.exe monitor

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

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

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

CLMonitor.exe trace –-parentProcessID 10256

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

CLMonitor.exe monitor –-attach

Building the project

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

How to stop compilation monitoring

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

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

You can also pass additional parameters when starting the analysis:

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

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

CLMonitor.exe abortTrace

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

To save the dump file, use the following command:

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

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

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

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

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

The Wrap Compilers interception mode (for Windows)

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

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

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

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

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

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

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

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

Compiler tracing (for Linux)

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

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

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

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

where:

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

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

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

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

You can also pass additional parameters when starting the analysis:

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

Visual Studio Code

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

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

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

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

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

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

Click Edit to set the following parameters:

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

Click Continue to run the analysis using the default settings.

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

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

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

A standard for improving reliability

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Dangerous code fragments in embedded projects

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

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

RT-Thread

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

The project was checked as of the cfda3b3 commit.

Fragment N1

PVS-Studio warnings:

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

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

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

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

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

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

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

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

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

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

Fragment N2

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

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

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

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

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

    default: break;                 // <=
  }

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

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

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

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

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

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

default:
    return;

Fragment N3

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

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

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

The fixed code:

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

Fragment N4

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

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

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

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

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

Two options are possible here:

The check is redundant because a valid object is always passed to the function input.
The check is necessary, but the compiler might remove it during optimization because it recognizes that the pointer is used further up in the code. In this case, a dereference of a null pointer occurs, resulting in undefined behavior. This article provides a more detailed look at a similar case, where the address of an object is obtained relative to a null pointer, followed by dereferencing the pointer.

To fix the error, we'll add a check at the beginning of the function. For example:

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

  if (!cond || !mutex)
  {
    return -RT_ERROR;
  }

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

  // ....
}

FreeRTOS

FreeRTOS was created by Richard Barry in 2003. Since 2017, it has been developed under Amazon Web Services. Its small kernel footprint and excellent portability across dozens of hardware platforms have made it a popular choice for microcontroller-based devices.

The project was checked as of the c73a397 commit.

Fragment N1

PVS-Studio warning: V557 Array overrun is possible. The value of 'uxTimerID' index could reach 21. TimerDemo.c 1167

static uint8_t ucAutoReloadTimerCounters[configTIMER_QUEUE_LENGTH + 1] = { 0 };
// ....

static void prvAutoReloadTimerCallback( TimerHandle_t pxExpiredTimer )
{
  size_t uxTimerID;

  uxTimerID = ( size_t ) pvTimerGetTimerID( pxExpiredTimer );

  if( uxTimerID <= ( configTIMER_QUEUE_LENGTH + 1 ) )     // <=
  {
    ( ucAutoReloadTimerCounters[ uxTimerID ] )++;
  // ....
}

This error is particularly sneaky and often slips through code reviews. Few reviewers stop to check an index boundary when the code appears to work correctly. Tests are also unlikely to catch it, which makes the error even harder to find. However, accessing an array out of bounds results in undefined behavior.

The issue stems from using a non-strict comparison <= to set the bounds of the uxTimerID index. As a result, uxTimerID can take the configTIMER_QUEUE_LENGTH + 1 value, which is also the size of the array. Accessing an element at that index results in going outside the array bounds.

The fixed code:

if( uxTimerID < ( configTIMER_QUEUE_LENGTH + 1 ) )

Fragment N2

PVS-Studio warning: V547 Expression 'i + 1 > (4 + 32)' is always false. trcSnapshotRecorder.c 831

static uint8_t writeInt8(void * buffer, uint8_t i, uint8_t value)
{
  TRACE_ASSERT(buffer != (void*)0, "writeInt8: buffer == NULL", 0);

  if (i >= MAX_ARG_SIZE)
  {
    return 255;
  }

  ((uint8_t*)buffer)[i] = value;

  if (i + 1 > MAX_ARG_SIZE)
  {
    return 255;
  }

  return ((uint8_t) (i + 1));
}

The error is that the second check, if (i + 1 > MAX_ARG_SIZE), is always false after the first check, if (i >= MAX_ARG_SIZE).

Once i passes the first check, i + 1 can no longer exceed MAX_ARG_SIZE. It's likely that one of the checks is redundant, or the second condition was intended to be different.

Zephyr

Zephyr launched in 2016 with Intel's support and is now being developed under the Linux Foundation. It targets IoT, embedded devices, and automotive systems, and features a modular architecture with a wide range of built-in subsystems.

The project was checked as of the c6da464 commit.

Fragment N1

PVS-Studio warning: V547 Expression 'conv->pad0_value > 0' is always true. cbprintf_complete.c 1224

static char *encode_float(/*....*/)
{
  // ....
  if ((decexp < 0) && (precision > 0)) {
    conv->pad0_value = -decexp;
    if (conv->pad0_value > precision) {
      conv->pad0_value = precision;
    }

    precision -= conv->pad0_value;
    conv->pad_postdp = (conv->pad0_value > 0); // <=
  }
  // ....
}

The analyzer reports that conv->pad0_value > 0 is always true. As a result, the conv->pad_postdp variable always receives the same value. Here's why the condition is always true:

As soon as execution enters the first if block, conv->pad0_value is assigned the -decexp value. Since decexp < 0, the result is always positive.
If execution enters the nested if block, the value remains positive because precision > 0.
As a result, conv->pad0_value is always greater than zero.

Most likely, the condition is redundant and can be removed. Alternatively, the initialization of pad0_value needs to be moved outside the if block. The final decision is up to the developers.

Fragment N2

PVS-Studio warning: V557 Array overrun is possible. The value of 'keep_cnt ++' index could reach 16. cbprintf_packaged.c 1143

int cbprintf_package_convert(/*....*/)
{
  // ....
  __ASSERT_NO_MSG(keep_cnt < sizeof(keep_str_pos));
  if (keep_cnt < sizeof(keep_str_pos)) {
    keep_str_pos[keep_cnt++] = arg_idx;
    keep_str_pos[keep_cnt++] = arg_pos;
  }
  // ....
}

This is a particularly interesting case. The developers correctly checked the array bounds but overlooked how the post-increment operator affects the index. Here's what happens:

the keep_cnt < sizeof(keep_str_pos) condition allows keep_cnt to reach N - 1, where N is the array size;
the first post-increment accesses the array at the N - 1 index and increments keep_cnt to N;
the second post-increment accesses the array at the N index and increments keep_cnt to N + 1.

Accessing outside the array bounds results in undefined behavior. We can fix the code by rewriting the condition as follows:

if (keep_cnt + 1 < sizeof(keep_str_pos))

Fragment N3

PVS-Studio warning: V779 Unreachable code detected. It is possible that an error is present. sched.c 345

#define z_except_reason(reason) do { \
    __EXCEPT_LOC();              \
    z_fatal_error(reason, NULL); \
  } while (false)

#define k_panic()  z_except_reason(K_ERR_KERNEL_PANIC)

void z_thread_halt(/*....*/)
{
  // ....
  if ((thread == _current) && !arch_is_in_isr()) {
    if (z_is_thread_essential(thread)) {
      k_spin_unlock(&_sched_spinlock, key);
      k_panic();                                   // <=
      key = k_spin_lock(&_sched_spinlock);         // <=
    }
    // ....
}

The analyzer detected unreachable code. The k_panic macro calls z_fatal_error, which terminates the system and never returns the control flow. As a result, the line that follows it is never executed.

Unfortunately, it's hard to recommend the right solution without more information. It's possible that this line simply doesn't belong here.

Fragment N4

PVS-Studio warning: V795 Please note that the size of the 'time_t' type is not 64 bits. After year 2038, the program will work incorrectly. clock.c 47

static void timespec_from_ticks(uint64_t ticks, struct timespec *ts)
{
  uint64_t elapsed_secs = ticks / CONFIG_SYS_CLOCK_TICKS_PER_SEC;
  uint64_t nremainder = ticks % CONFIG_SYS_CLOCK_TICKS_PER_SEC;

  *ts = (struct timespec){
    .tv_sec = (time_t)elapsed_secs,
    /* For ns 32 bit conversion can be used since its smaller than 1sec. */
    .tv_nsec = (int32_t)k_ticks_to_ns_floor32(nremainder),
  };
}

The problems of the future are already knocking at the door. In just 12 years, on January 19, 2038, this project will run into the classic Year 2038 problem.

The root cause is that time_t will no longer behave as expected. Its behavior will depend on the platform because the type stores the number of seconds since January 1, 1970. After the cutoff date, the value will overflow, causing incorrect time calculations.

How to fix issues

To keep dangerous code patterns out of your codebase, it's important to take a comprehensive approach to software quality. This may include code reviews, manual and automated testing, dynamic analysis, and other verification techniques.

Static code analysis is one of the most effective and cost-efficient ways to catch issues early in the development process. Try PVS-Studio on your project for free and explore pricing for the full version.

If you're still looking for a reason to adopt static analysis, here are five reasons why it is important for business.

Additional links:

Inside cloud-native Java: Exploring Quarkus

Unicorn Developer — Mon, 03 Aug 2026 14:12:58 +0000

Java keeps finding itself on cloud nine these days, all because of cloud hosting. With more and more applications and services adopting cloud-native architectures, it's a good time to take a closer look at Quarkus, which is one of the leading frameworks for building high-performance cloud applications.

Intro

We regularly check open-source projects with our PVS-Studio analyzer and publish articles about the errors we find. Articles like these give readers a better understanding of static analysis, highlight the most common errors, and showcase the nuances of developing in a particular language.

Large-scale projects are especially interesting to look at, since they're constantly evolving. They have massive codebases, and their development pulls in a wide range of approaches and technologies. That variety carries over into the bugs themselves.

This time we picked the popular project—Quarkus, a modern framework built for developing high-performance cloud applications in Java, using technologies that have become standard in enterprise development: microservices, DI containers, and more.

Quarkus focuses on production performance by shifting much of the work to the build phase: including reading part of the application configuration, scanning the classpath for annotated classes, and constructing a model of the application. Quarkus apps also compile easily into a native image.

This makes it clear we're dealing with a large, complex project, so we decided to see what errors we could find. We ran our analysis on this commit. Here are the results.

How to fix a Problem Child

No, this isn't a lecture on parenting. I'll just remind you of some of the pitfalls hiding in Java's inheritance hierarchy. Here's the code we'll be looking at.

Snippet 1

public class InterceptorInfo extends BeanInfo 
                             implements Comparable<InterceptorInfo> {
  private final Set<AnnotationInstance> bindings;
  .... 
  @Override
  public String toString() {
    return "INTERCEPTOR bean [bindings=" + bindings + 
           ", target=" + getTarget() + "]"; 
  }
}

Notice that the toString method uses the bindings field of the InterceptorInfo class. Now let's look at the constructor of the parent class BeanInfo:

BeanInfo(....) {
  ....
  this.identifier = Hashes.sha1_base64(
            (identifier != null ? identifier : "") + 
            toString() + beanDeployment.toString()
           );
  ....
}

To finally put all the pieces of the puzzle together, here's the InterceptorInfo class constructor:

InterceptorInfo(. . . ., Set<AnnotationInstance> bindings) {
  super(. . . .);
  this.bindings = bindings;
  ....
}

Let's trace through what's actually happening here. When InterceptorInfo is initialized, the constructor of its parent class, BeanInfo, gets called first. That constructor, in turn, calls the toString method, which is overridden in the InterceptorInfo class. At this point, the toString method uses the bindings field before it's been initialized. The resulting string ends up reflecting the object's state before initialization.

We covered this issue in more detail, along with how to deal with it, in a separate article.

The PVS-Studio warning:

V6052 Calling overridden 'toString' method in 'BeanInfo' parent-class constructor may lead to use of uninitialized data. Inspect field: bindings. InterceptorInfo.java 265

Lost and found

Forgotten, lost, or mixed-up code snippets tend to show up in every project sooner or later, and Quarkus isn't an exception.

Snippet 2

public void build(Path projectDir) {
  .... 
  try {
    ModelUtils.persistModel(projectDir.resolve("pom.xml"), model);
  } catch (IOException e) {
    throw new IllegalStateException();   // <= 
  }
}

The class method is responsible for building the Maven project model and its dependencies. As the snippet shows, saving the model file can throw an exception, and that exception gets replaced by an IllegalStateException. This isn't a great practice, because if something goes wrong, the exception thrown from the build method won't carry any information about the actual error. No one will ever know what skeletons are hiding in that closet.

The PVS-Studio warning:

V6118 The original exception object 'IOException' was swallowed. Cause of original exception could be lost. MvnProjectBuilder.java 122

Snippet 3

Foo.Bar bar1 = new Bar(new ArrayList<>());
event1.fire(bar1);
assertEquals(1, bar1.getNames().size());     // <= 
assertEquals("bazinga", bar1.getNames().get(0));

Foo.Bar bar2 = new Bar(new ArrayList<>());
event2.fire(bar2);
assertEquals(1, bar1.getNames().size());     // <= 
assertEquals("bazinga", bar2.getNames().get(0));

This is an excerpt from tests that verify the event mechanism. Two instances of Foo.Bar get created and tested here. It's easy to see that the second block of test code is copy-pasted from the first. The duplicated line assertEquals(1, bar1.getNames().size()), still references bar1 instead of bar2, so the check ends up testing the wrong object's state.

The PVS-Studio warning:

V6072 Two similar code fragments were found. Perhaps, this is a typo and 'bar2' variable should be used instead of 'bar1'. MockEventTest.java 40

By the way, we've added the exact same rule to our new JavaScript and TypeScript analyzer.

Snippet 4

public class PathTreeBuilder {
  private List<String> includes;
  private List<String> excludes;
  ....
  List<String> getIncludes() {
    return includes;
  }

  List<String> getExcludes() {
    return includes;       // <= 
  }
}

As the class name suggests, PathTreeBuilder creates a PathTree instance, which is used to easily manage a project's dependencies as a tree structure. The builder has methods for populating the includes and excludes fields, but the getExcludes method mistakenly returns the includes field instead.

The PVS-Studio warning:

V6091 Suspicious getter implementation. The 'excludes' field should probably be returned instead. PathTreeBuilder.java 58

Snippet 5

private static boolean isIgnored(DotName classDotName) {
  String className = classDotName.toString();
  if (className.startsWith("java.util.") 
      || className.startsWith("java.lang.")
      || className.startsWith("org.hibernate.engine.spi.")
      || className.startsWith("jakarta.persistence.")
      || className.startsWith("jakarta.persistence.")    // <=
  ) {
    return true;
  }
  return false;
}

The method is used in the JpaJandexScavenger class to filter the classes needed for the integrated Hibernate ORM to work. The class itself determines in advance which types it needs. As mentioned in the Intro, Quarkus aims to move part of its logic to build time, and JpaJandexScavenger is a direct implementation of that idea.

In the method body, you can see the jakarta.persistence. package repeated in the logical condition:

className.startsWith("jakarta.persistence.") ||
className.startsWith("jakarta.persistence.")

Given what this method is for, it's possible that another restriction was meant to go here and got left out. This probably won't affect functionality, but the final size of the application could grow slightly, since more classes end up covered by metadata than necessary. Or maybe it's all simpler than that, and it's just an extra check that was left in by mistake.

The PVS-Studio warning:

V6001 There are identical sub-expressions 'className.startsWith("jakarta.persistence.")' to the left and to the right of the '||' operator. JpaJandexScavenger.java 621

When the math isn't mathing

Numbers always have their own ways of going wrong.

Snippet 6

@ConsumeEvent("address-4")
CompletionStage<Long> listenAddress4(int i) {
  return CompletableFuture.completedFuture((long) (i + 1));
}

If the variable i equals to Integer.MAX_VALUE, adding one to it causes an overflow, and the result becomes Integer.MIN_VALUE. We can prevent this by casting one of the operands to long. Although there's a type cast in the example, it's applied to the result of the operation, so it doesn't actually prevent the overflow.

The PVS-Studio warning:

V6117 Possible overflow. The expression will be evaluated before casting. Consider casting one of the operands instead. CodecRegistrationTest.java 195

Snippet 7

@Override
public void apply(SocketSettings.Builder builder) {
  if (config.connectTimeout().isPresent()) {
    builder.connectTimeout((int) config.connectTimeout().get()       // <= 
                                       .toMillis(), TimeUnit.MILLISECONDS); 
  }
  if (config.readTimeout().isPresent()) {
    builder.readTimeout((int) config.readTimeout().get()        // <=
                                    .toMillis(), TimeUnit.MILLISECONDS);
  }
}

Here's another cast that can lead to an overflow. Its purpose is unclear, especially since both connectTimeout and readTimeout on the builder variable take a long.

The PVS-Studio analyzer issues the following warnings for these spots:

V6106 Casting expression to int type before implicitly casting it to other type may be excessive or incorrect. MongoClients.java 289

V6106 Casting expression to int type before implicitly casting it to other type may be excessive or incorrect. MongoClients.java 286

Snippet 8

static <T> List<T> takeLast(List<T> list, int n) {
  if (n < 1 || n > list.size()) {
    throw new IndexOutOfBoundsException(n);
  }
  if (list.isEmpty()) {   // <= 
    return list;
  }
  return list.subList(list.size() - n, list.size());
}

The method takes the last n elements from list. The check above implies we can't request fewer than one item, or more than the list actually contains. But the check also implies the list itself can't be empty. If we're taking at least one element from the list, the list has to contain at least one element already. So, the check right below, list.isEmpty(), always evaluates to false. If the intent was to handle an empty list as a special case, this check won't catch it, and it needs to be reworked.

The PVS-Studio warning:

V6007 Expression 'list.isEmpty()' is always false. CollectionTemplateExtensions.java 57

Snippet 9

if (errorRate != -1.0) {
  list.add("ERROR");
  list.add(new BigDecimal(errorRate).toPlainString()); // Prevent E notation
}

This one's worth a closer look. If we pass 0.1 into the BigDecimal constructor, what actually gets stored is 0.1000000000000000055511151231257827021181583404541015625. This "tail" is a natural feature of how real numbers are represented in a computer. If you're curious why this happens, here's a link with the theory behind it.

Now let's see how to create the object without that tail showing up as a surprise. The standard library provides the BigDecimal#valueOf method for exactly this, and it implements some clever logic:

public static BigDecimal valueOf(double val) {
  .... 
  var fmt = FormattedFPDecimal.valueForDoubleToString(Math.abs(val));
  long s = fmt.getSignificand();
  .... 
}

Roughly speaking, here's what happens: the method takes the binary representation of a real number and converts it into a decimal representation, one that's correctly rounded and as short as possible. For the number we're discussing, that string comes out to exactly 0.1. So the BigDecimal#valueOf method will preserve our exact value.

But it wasn't always like that.
This method first appeared in Java 5 and looked completely different:

public static BigDecimal valueOf(double val) { 
  return new BigDecimal(Double.toString(val));
}

A string was used instead of a decimal representation here, but the problem was solved the same way overall.

By the way, the BigDecimal#valueOf method still refers to Double#toString() in its Javadoc, even though it now uses different methods under the hood these days. The core of the algorithm hasn't changed though, and it's well documented in the Javadoc for the Double#toString() method.

Before Java 5, the BigDecimal(String) constructor had already existed and was the recommended choice over BigDecimal(double).

Such nuances are particularly important in high-precision computing systems, where even small errors can lead to unexpected consequences.

The PVS-Studio warning:

V6068 Constructor call can result in imprecise representation of the initialized value. BfInsertArgs.java 95

New Year's frenzy

If you suddenly find yourself in the past or the future after celebrating New Year's, don't panic, it's just a bug.

Snippet 10

public class WebSocketNextJsonRPCService implements ConnectionListener {
  private static final DateTimeFormatter FORMATTER = 
    DateTimeFormatter.ofPattern("YYYY-MM-dd HH:mm:ss");  
  .... 
}

At first glance, there's nothing wrong here at all, but take a closer look at the date format string: YYYY-MM-dd. Still looks fine on the surface, but there's a catch.

If the current date is, say, January 1, 2027, this format will display it as January 1, 2026.

That's because YYYY displays the year based on the week number, not the calendar date. There's a specific rule for it too: if most of the week falls in the previous year, that's the year that gets shown. In our example, January 1 falls on a Friday, so most of that week belongs to 2026.

The reverse happens when only a small part of the week falls in the outgoing year. December 31, 2024, for instance, would show up as December 31, 2025, in this format, since most of that week belongs to 2025. A whole year gone, and nobody even noticed.

This bug is unusual enough that we devoted a separate article to it.

We can fix this by replacing YYYY with yyyy, which is exactly what PVS-Studio says:

V6122 Usage of 'Y' (week year) pattern was detected: it was probably intended to use 'y' (year). WebSocketNextJsonRPCService.java 39

The broken windows theory

We explained what this theory is and how it applies to development in the article. Now let's see once again how it plays out in practice.

Snippet 11

@Override
public <T> T getClaim(String claimName) {
  if (claimName.equals(Claims.groups)) {
    return (T) getGroups();
  } else if (claimName.equals(Claims.groups)) {  // <=
    return (T) getAudience();
  } else if (claimName.equals(Claims.exp)) {
    return (T) Long.valueOf(getExpirationTime());
  } else if (claimName.equals(Claims.iat)) {
    return (T) Long.valueOf(getIssuedAtTime());
  } else if (claimName.equals(Claims.aud)) {
    return (T) getAudience();
  }
  return (T) claims.getClaim(claimName);
}

The PVS-Studio warning:

V6003 The use of 'if (A) {...} else if (A) {...}' pattern was detected. There is a probability of logical error presence. CognitoPrincipal.java 38

Here's what's happening: the second condition in the if-else chain has a typo, checking Claims.groups again, while still returning the result of the getAudience method call. One might argue that it's no big deal, since the correct condition appears later in the chain, and the second check, claimName.equals(Claims.groups), will never be true at that point anyway, since it already failed the first condition. But that's not really the issue here. The warning is issued for the amazon-lambda-rest package. Now let's take a look at another warning nearby, in the amazon-lambda-http package:

@Override
public <T> T getClaim(String claimName) {
  if (claimName.equals(Claims.groups)) {
    return (T) getGroups();
  } else if (claimName.equals(Claims.groups)) {  // <=
    return (T) getAudience();
  } else if (claimName.equals(Claims.exp)) {
    return (T) Long.valueOf(getExpirationTime());
  } else if (claimName.equals(Claims.iat)) {
    return (T) Long.valueOf(getIssuedAtTime());
  } else if (claimName.equals(Claims.aud)) {
    return (T) getAudience();
  }
  return (T) getClaims().getClaims().get(claimName);
}

Same exact code, same exact bug. The only difference is in the last line. That's how buggy code spreads through a project via simple copy-paste.

PVS-Studio triggers in the second package: V6003 The use of 'if (A) {...} else if (A) {...}' pattern was detected. There is a probability of logical error presence. CognitoPrincipal.java 41

Snippet 12

@BuildStep
@Record(ExecutionTime.RUNTIME_INIT)
VertxWebRouterBuildItem initializeRouter(....) {
  .... 
  List<RouteBuildItem> redirectRoutes = new ArrayList<>();
  .... 
  if (frameworkRouterCreated) {    
    if (redirectRoutes.size() > 0) {    // <= 
      recorder.setNonApplicationRedirectHandler(
        nonApplicationRootPath.getNonApplicationRootPath(),
        nonApplicationRootPath.getNormalizedHttpRootPath()
      );
      redirectRoutes.forEach(route -> recorder.addRoute(
                           httpRouteRouter, 
                           route.getRouteFunction(),
                           recorder.getNonApplicationRedirectHandler(),
                           route.getType()
                          )
      );
    }
  }
  return new VertxWebRouterBuildItem(httpRouteRouter, mainRouter, 
                                     frameworkRouter, managementRouter,
                                     mutinyRouter);
}

The PVS-Studio warning:

V6007 Expression 'redirectRoutes.size() > 0' is always false. VertxHttpProcessor.java 392

Here, part of the logic never runs, since the redirectRoutes collection never gets populated within the method and is never passed anywhere either. We decided to look at the project's history for this file, and we found a commit from 2021 with some curious lines that had been removed:

if (httpBuildTimeConfig.redirectToNonApplicationRootPath && 
    route.isRequiresLegacyRedirect()
) {
  redirectRoutes.add(route);
}

So, what do broken windows have to do with any of this? Extra code left in one place can lead to the same kind of code appearing elsewhere in the project. Take that abandoned code, for example: it uses a method that never gets removed, because it's still needed right there. As a result, the abandoned code now touches two classes, and this chain could keep extending further. The end result is a bloated codebase that gets harder and harder to reason about.

Don't trust environment variables

Here's the code the analyzer highlighted.

Snippet 13

static final boolean IS_CYGWIN = OS.WINDOWS.isCurrent()
        && System.getenv("PWD") != null
        && System.getenv("PWD").startsWith("/");

The code reads the PWD environment variable, usually used to indicate the current working directory. It comes with its own quirks though: it might not be set at all, or it might be overridden from outside. . For consistent results, it's safer to use the JVM system property user.dir, since it's guaranteed to be set when the application starts and can't be changed externally.

The PVS-Studio warnings for this code:

V6110 Using the 'PWD' environment variable could be unsafe or unreliable. Consider using trusted system property 'user.dir' instead. TerminalUtils.java 27

V6110 Using the 'PWD' environment variable could be unsafe or unreliable. Consider using trusted system property 'user.dir' instead. TerminalUtils.java 28

The project also has several similar warnings for other values, which should likewise be retrieved through System.getProperty:

V6110 Using the 'HOME' environment variable could be unsafe or unreliable. Consider using trusted system property 'user.home' instead. Constants.java 11

V6110 Using the 'USER' environment variable could be unsafe or unreliable. Consider using trusted system property 'user.name' instead. AnalyticsService.java 231

Challenges of multithreaded programming

Multithreaded code punishes even small mistakes.

Snippet 14

public class KubernetesDevUIProcessor {
  static volatile List<Manifest> manifests;
  public List<Manifest> getManifests() throws BootstrapException {
    if (manifests == null) {
      synchronized (Holder.class) {
        if (manifests == null) {
          manifests = new ArrayList<>();
          .... 
          try (CuratedApplication bootstrap = quarkusBootstrap.bootstrap()) {
            .... 
            for (var entry : context.entrySet()) {
              manifests.add(
                             new Manifest(entry.getKey(), 
                             new String(entry.getValue()))
                            );
            }
          }
        }
      }
    }
    return manifests;
  }
}

This is an example of an incorrect implementation of the double-checked locking pattern applied to the manifests field. If you want to know how this pattern works and why it's used, we cover that in the article.

When the thread enters the synchronization block, it initializes the manifests field with an empty list and then proceeds to populate it. In other words, it was originally assumed that the field would become available once it had been created and populated with values. However, the publication occurs right after manifests is initialized, so another thread might end up with a list that's been created but not yet populated.

Fixing this is straightforward: just initialize the field with a fully built list from a local variable.

The PVS-Studio warning:

V6082 Unsafe double-checked locking. Object was assigned to the field before it was initialized. KubernetesDevUIProcessor.java 66

Snippet 15

public class VertxUdpMetrics implements DatagramSocketMetrics {
  private volatile Tags tags;

  @Override
  public void listening(String localName, SocketAddress localAddress) {
    tags = tags.and("address", NetworkMetrics.toString(localAddress));   // <= 
  }
}

The tags field has been marked with the keyword volatile. Just to recap, here's what that means in Java: if one thread modifies a variable, another thread immediately sees that change. However, this works flawlessly for atomic operations. If the logic involves several actions, a completely different approach is required to avoid a race condition.

To see what's happening here, suppose two threads call the listening method at the same time. Both entered the method, both created a new instance using the and method, and both attempted to store the new value in the tags variable.

These three operations don't add up to a single atomic operation, so the volatile keyword won't help here. A different approach is needed instead, like making the method synchronized.

The PVS-Studio warning:

V6074 Non-atomic modification of volatile variable. Inspect 'tags'. VertxUdpMetrics.java 37

Attention, please!

This is a case where carelessness led to buggy, unnecessary code.

Snippet 16

Let's break this code down step by step.

public class TemplateHtmlBuilder {
  private static final String HEADER_TEMPLATE_NO_STACK = "<h1>%1$s</h1>\n" +
           "%2$s \n" +
           "<div class=\"container content\">\n";
  private static final String HTML_TEMPLATE_START_NO_STACK = "" +
             "<!doctype html>\n" +
             "<html lang=\"en\">\n" +
             "<head>\n" +
             "    <title>%1$s%2$s</title>\n" +
             "    <meta charset=\"utf-8\">\n" +
             "</head>";
 ....
}

Here we see two HTML templates stored in these fields. Looking closely, we'll notice that both the first and second templates contain placeholders for two string variables.

Now let's take a look at how they're used:

public TemplateHtmlBuilder(...., 
        String title, 
        String details
) {
  ....
  result = new StringBuilder(String.format(HTML_TEMPLATE_START_NO_STACK, 
                        escapeHtml(title),
                        subTitle == null || subTitle.isEmpty() ? "" : " - " + 
                        escapeHtml(subTitle), CSS));
  result.append(String.format(HEADER_TEMPLATE_NO_STACK, 
                escapeHtml(title),
                escapeHtml(details), 
                actionLinks.toString()
               ));
}

When using the HEADER_TEMPLATE_NO_STACK and HTML_TEMPLATE_START_NO_STACK fields, the template gets populated with three arguments in both cases, even though the lines themselves only have two slots. This same method contains identical lines using the exact same arguments, but with templates built for three arguments. This looks like a typical copy-paste mistake, where the extra arguments never got removed.

The PVS-Studio warning:

V6046 Incorrect format. A different number of format items is expected. Arguments not used: 3. TemplateHtmlBuilder.java 325

V6046 Incorrect format. A different number of format items is expected. Arguments not used: 3. TemplateHtmlBuilder.java 328

Snippet 17

public void boot(...., Optional<FunctionInitializedBuildItem> hasFunctions) {
  if (!hasFunctions.isPresent() || hasFunctions.get() == null) // <= 
    return;
}

The method takes a hasFunctions parameter of type Optional, which is used to perform a very strange check:

!hasFunctions.isPresent() || hasFunctions.get() == null

Here's a quick refresher on what Optional::isPresent does:

public boolean isPresent() {
  return value != null;
}

In this specific case, only the call to Optional::isPresent was needed, since Optional::get throws an exception if the value is actually null.

The PVS-Studio warning:

V6007 Expression 'hasFunctions.get() == null' is always false. FunqyHttpBuildStep.java 77

Snippet 18

if (typeInfo == null || (typeInfo != null &&   
    typeInfo.endsWith(SectionHelperFactory.HINT_METADATA))
) {
  continue;
}

This one's straightforward: the check for typeInfo != null is unnecessary, since the opposite condition was already checked first.

The PVS-Studio warning:

V6007 Expression 'typeInfo != null' is always true. QuteProcessor.java 920

Snippet 19

if (persistenceProviderResolver == null ||
     (persistenceProviderResolver != null       // <= 
      && !(persistenceProviderResolver instanceof
               MultiplePersistenceProviderResolver
           )
      )
) {
  ....
}

This warning is similar to the previous one, but here even the check for equality with null is unnecessary. In fact, instanceof returns false if the object passed to it is null. Since this checks that persistenceProviderResolver is not of type MultiplePersistenceProviderResolver, this bulky if statement can be simplified to:

!(persistenceProviderResolver instanceof MultiplePersistenceProviderResolver)

The PVS-Studio warning:

V6007 Expression 'persistenceProviderResolver != null' is always true. PersistenceProviderSetup.java 28

Snippet 20

for (String name : res.headers().names()) {
  if (name.equalsIgnoreCase("Transfer-Encoding")) {     // <= 
    continue; // ignore transfer encoding, 
            // chunked screws up message and response
  }
  for (String v : res.headers().getAll(name)) {
    if (name.equalsIgnoreCase("Transfer-Encoding")       // <=
        && v.contains("chunked")) { 
      continue;
    }
    responseBuilder.getMultiValueHeaders().add(name, v);
  }
}

The name variable gets checked for equality with the Transfer-Encoding string before the inner loop and on every iteration of it. This unnecessary operation just bloats the code.

The PVS-Studio warning:

V6007 Expression 'name.equalsIgnoreCase("Transfer-Encoding")' is always false. LambdaHttpHandler.java 104

Snippet 21

while (
       !ResteasyReactiveDotNames.OBJECT.equals(currentClazz.name()) && 
       currentClazz != null              // <=
) { 
  ....
}

And here's the cherry on top: currentClazz gets dereferenced first, and the null check comes only after.

The PVS-Studio warning:

V6060 The 'currentClazz' reference was utilized before it was verified against null. ResteasyReactiveProcessor.java 1125

Wrapping up

We've now gone through some interesting bugs and suspicious spots we managed to find in the Quarkus source code. We've checked other major projects too, and found plenty of interesting things there as well:

By the way, in the Quarkus repository, like in many modern projects, you can find .md files meant for AI agents. But no matter how powerful a tool AI is, it still makes sneaky mistakes sometimes, like the ones we already covered in the articles:

And that wraps up this article. If you'd like to check your own project, we've got a free trial of the PVS-Studio analyzer for you, you can get it here.

Webinar: Let's make a programming language. Functions

Unicorn Developer — Mon, 03 Aug 2026 13:49:23 +0000

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

In the previous session, we introduced variables — they could be declared, reference one another, and were resolved through a global hash table. Now it's time to add one of the core building blocks of any language: functions.

Implementing functions is really a story about scopes and name resolution. We'll explore how identifiers are looked up across different scope levels: the global scope, function scopes with their own variables, and nested local scopes inside function bodies. What happens when the same variable name exists in multiple scopes? How does the compiler determine which one to use?

In this webinar, our speaker Yuri will walk through the implementation step by step, demonstrating how functions, scopes, and symbol lookup are built in code using C++. Along the way, you'll gain a deeper understanding of one of the fundamental mechanisms behind modern programming languages.

Join us live to dive deeper into compiler design, ask your questions, and build a programming language from scratch together.

The series is aimed at developers who want to go beyond just using languages and start understanding how they're built. Whether you've been with us from the beginning or are jumping in now, this is a great place to start.

If you missed any of the previous sessions, don't worry. All registered participants get access to the recordings. You can also catch up on YouTube or the PVS-Studio website:

First talk: Let's make a programming language. Intro
Second talk: Let's make a programming language. Grammars
Third talk: Let's make a programming language. Lexer
Fourth talk: Let's make a programming language. Parser
Fifth talk: Let's make a programming language. AST
Sixth talk: Let's make a programming language. Variables

Register to join the session. All registered participants will receive the recording of this webinar, along with recordings of all previous webinars in the series, after the webinar has concluded.

Join us on August 20, 1:00 PM UTC+1!

P.S. Don't forget to check your inbox and confirm your registration!

Game++. Part 2.1: Types of optimization

Unicorn Developer — Fri, 31 Jul 2026 11:48:17 +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.

Wikipedia defines optimization as the process of improving a system to increase its efficiency or reduce its resource consumption. In game development, those words hit harder, since every game runs on a tight budget. On one side of the scale sit CPU time, memory, and frame time; on the other, the player and the market, with their expectations around graphics, physics, AI, and overall experience. That scale almost never tips in the developer's favor.

Optimization should always start with the big picture. Random small tweaks waste time—what matters is finding the real bottlenecks: where exactly performance drops, and which subsystems cost more than they give back. This is where profilers, performance counters, and tracing tools come into play. The process looks like this: locate a trouble spot, measure its impact, try an improvement, and measure again. If nothing improves, roll back and look for the next candidate.

Here are the steps to follow:

Benchmark—build a reproducible example of the problem scenario.
Measure—establish a baseline for memory and resource consumption.
Detect—find the part of the program that makes the poorest use of resources.
Solve—change how it works to improve resource usage.
Check—confirm through measurement that the improvement actually happened.
Repeat—go back to the first step until you hit your performance goals.

There's a more vivid concept—MEDAL:

Measure > Examine > Develop > Assess (Check results) > Loop.

An experienced developer treats optimization as a data-driven process, not a bag of tricks. Even so, it pays to keep proven techniques in your back pocket—for memory management, multithreading, rendering, math, and so on—and to pair them with personal experience and tooling to get a measurable result without wasting time. Hands-on experience is essential here: without practice or good mentors, learning to spot problem areas can be difficult. I've always been amazed by developers' ability to run demanding computations on relatively "weak" hardware, and by the tricks they use to keep applications running fast. This applies not only to game engines but also to databases, control systems, and the like. The gap becomes especially obvious when porting relatively recent games (PS3-generation and later) to handhelds like the Nintendo Switch and Steam Deck, or to mobile devices. In terms of raw performance, the Nintendo Switch hasn't moved far beyond the PlayStation 3, so attempts to port demanding titles built for at least the next console generation (PS4) run into significant and stubborn problems. Table 3.1 compares three generations of gaming hardware. It shows which solutions can be ported without major compromises, and what level of optimization developers need to focus on for each.

Component	PlayStation 3	Nintendo Switch (portable)	Steam Deck
CPU	Cellx1 PPE + x6 SPE ~25 GFlops	4× ARM Cortex-A57 1.02 GHz ~25 GFlops	AMD Zen 2 2.4–3.5 GHz (~448 GFlops)
GPU	NVIDIA (~GeForce 7800) ~192 GFlops	NVIDIA Maxwell GM20B ~157 GFlops	AMD RDNA 2 ~1,6 TFlops
RAM	256 MB XDR 256 MB GDDR3 ~25.6 GB/s (GPU)	4 GB LPDDR4 ~25.6 GB/s	16 GB LPDDR5 ~88 GB/s
API	Proprietary	OpenGL ES 3.2 / Vulkan / NX	OpenGL3+ / Vulkan

Table 3.1. Comparison of gaming platform specifications

From a CPU standpoint, the PS3 uses the Cell architecture with one main PPE core and six active SPE co-processors. In real game workloads, the performance of this configuration is generally estimated at around 20–30 GFLOPS, though fully leveraging Cell's potential is notoriously difficult.

The Nintendo Switch has a 4-core ARM Cortex-A57 running at 1.02 GHz, but effectively it's a 3-core machine, since one core is always reserved for the system. It delivers roughly 20–25 GFLOPS under typical loads. Despite the architectural differences, both CPUs perform at a similar level. The GPU picture is a little different. The PS3's RSX is an adapted GeForce 7800 with peak performance around 192 GFLOPS and an outdated shader model. The Switch uses a GPU based on NVIDIA's Maxwell architecture (Tegra X1): in handheld mode it runs at reduced clocks, delivering about 157 GFLOPS, while docked performance can reach 393 GFLOPS.

As for RAM, the Switch is powered by 4 GB of LPDDR4 offering about 25.6 GB/s of bandwidth, while the PS3 has 256 MB of XDR for the CPU and 256 MB of GDDR3 for the GPU, with roughly the same bandwidth. The Switch slightly wins on memory capacity, but not on bandwidth. In any case, it's the Steam Deck that sets today's baseline. Moving beyond that level, though, is no longer feasible, purely because of technical limitations. This comparison is really just a sketch. Once the Steam Deck 2 arrives, the Switch goes to the PS3 league, and suddenly the bar is raised for everyone. The optimization levels stay the same, with the same set of problems and solutions, and just backed by more resources.

A game is demanding software, often with soft real-time requirements, whether you're targeting a PS3 or the latest Steam Deck. Acceptable performance is non-negotiable—otherwise the experience suffers and nobody buys the game. There's a small upside when porting to mobile platforms: the hardware tends to be fixed. On smartphones, though, you're staring into a jungle of CPUs, GPUs, and runtime environments. Consoles fare better here, since their hardware specs change only every few years.

When porting a game, optimization can be split into several levels: architecture, algorithms, and code.

Architecture-level optimizations (~50% gain)

Architecture is about the bones of the system: how modules interact, how data sits in layers, the whole memory allocation dance (custom allocators vs. system malloc, object pooling vs. free-form allocation, dynamic vs. allocation-free), and the threading approach (single-threaded, multi-threaded, shared state, actor-based concurrency). A sub-optimal architecture means excessive memory consumption, sluggish execution, idle threads, resource contention, or expensive access patterns.

Fixing architectural flaws requires large investments of time and people to refactor the game's core subsystems or engine, which often means rewriting fundamental components like the object management system, renderer, or memory system. Examples include moving from an inheritance-and-components model to an Entity Component System (ECS) architecture, replacing the object allocation mechanism, or reorganizing the command system. These architectural shifts deliver the most dramatic performance gains—smarter memory access can boost performance, and a well-tuned thread management model keeps all CPU cores busy, with idle time dropping sharply.

However, late-stage architectural changes create a domino effect throughout the entire codebase, requiring months of fixes and expensive regression testing and makes such optimizations virtually impossible right before a game's release or when porting to new platforms.

Algorithm/data structure-level optimizations (~30%)

Algorithms determine how efficiently the program runs. The right choice can literally save your frame rate: replacing a plain iteration over array elements (complexity O(n)) with a binary search on a sorted array (O(log n)) or a hash-table lookup (O(1)) yields a massive speedup as data volume grows. In an array of a million elements, a linear search might cost a million operations, a binary search only about 20, and a hash table finds the element almost instantly. We rarely have arrays that large, but a handful of frequently called hot spots can still rack up that million accesses.

But theoretical algorithmic complexity doesn't always match real-world performance, because of how modern hardware works. Processors use caches (L1, L2, L3), and algorithms that access data sequentially get a huge boost from hardware prefetching. As a result, a simple linear scan over a tightly packed array can significantly outperform a hash-table lookup when the data fits in the L1 cache. Linked lists, theoretically efficient for insertions, end up slower than dynamic arrays in practice because of pointer-chasing. And since CPUs rely on branch prediction, predictable code runs faster—a straightforward algorithm with simple logic often leaves a complex, branch-heavy one in the dust.

That's why developers often look beyond Big-O notation and weigh real-world conditions: data size, memory access patterns, branch predictability, and the architecture of the target hardware.

Development includes profiling code on real data and writing benchmarks for the tricky sections. In real projects, a "naive" solution often beats the textbook approach: data locality works in its favor, and there's no heavy scaffolding to drag along. Here's a typical example:

// The example of search optimization

bool slow_contains(const std::vector<int>& vec, int target) {
  // Call 'find' each time

  return std::find(vec.begin(), vec.end(), target) != vec.end();
}

bool fast_contains(const std::vector<int>& sorted_vec, int target) {
  // Simple optimization,
  // use binary search for sorted array

  return std::binary_search(sorted_vec.begin(),
                            sorted_vec.end(), target);
}

Source code-level optimizations (~10%)

Local-level optimizations target individual blocks of code, functions, or bounded algorithmic scopes. They focus on fine-tuning a solution to raise performance and lower overhead. These small-scale optimizations usually touch only limited parts of the program and can be handled in a single code review: up to a hundred changes and maybe ten files at once.

Key areas of focus include heapless logic (i.e. implementing algorithms and data structures on the stack rather than the heap), object pools, and specialized allocators. Loop unrolling improves instruction-level parallelism when the compiler can't do it automatically due to code complexity. Other techniques include inlining "hot" functions, introducing SIMD for vectorized computation, minding data locality, and following the access patterns. The optimization process often involves detailed profiling with tools like Intel VTune, PIX, Razor, Tracy, or a game engine's built-in profiler. The analysis covers inefficient instructions, cache miss rates, excessive virtual-function calls, hidden copies when passing parameters, and expensive object operations. In most cases, fixing these issues requires trade-offs between code readability and the solution you implement, so these optimizations apply only to code that eats up most of the frame time.

Loop optimization is easily one of the most common tasks at this level. Developers regularly run into nested loops the compiler can't refine but that can be simplified or swapped out for smarter algorithms. For example, if an inner loop is searching through a collection, consider preparing the data structure in advance or using a hash table to avoid redundant passes.

Sometimes simply moving loop invariants outside the loop or changing the iteration order is enough to reduce the load on the CPU:

void calculatePhysicsSlow(vector<float>& pos, vector<float>& vel, int frameStep)
{
  for (int i = 0; i < iterations; ++i) {
    for (size_t j = 0; j < positions.size(); ++j) {
      // Invariant computations are repeated,
      // the compiler may not spot them in difficult cases

      float gravity = world->getGravity(); float damping = object->getDamping();
      float timeStep = getDeltaTime() / frameStep;

      vel[j] += gravity * timeStep; vel[j] *= damping;
      pos[j] += velocities[j] * timeStep;
    }
  }
}

--------------------------------------------------------------------------

void calculatePhysicsFast(vector<float>& pos, vector<float>& vel, int frameStep)
{
  // Invariant computations were moved beyond loop boundaries

  float gravity = world->getGravity(); float damping = object->getDamping();
  float timeStep = getDeltaTime() / frameStep;
  const float gravityTimeStep = gravity * timeStep;

  for (int i = 0; i < iterations; ++i) {
    for (size_t j = 0; j < positions.size(); ++j) {
      velocities[j] += gravityTimeStep;
      velocities[j] *= damping;
      positions[j] += velocities[j] * timeStep;
    }
  }
}

Modern compilers with optimizations enabled can handle these transformations automatically, but once pointers, virtual functions, or convoluted logic enter the picture, you still have to step in to squeeze out maximum performance. Hoisting loop-invariant code is a fundamental optimization based on the loop-invariant code motion principle: you take expressions whose value never changes across iterations and move them out of the loop so they're computed once. Invariant candidates include operations on constants, accesses to unchanged variables, math expressions with fixed values, and calls to functions with deterministic results.

For example, evaluating deltaTime / iterations, sin(angle) for a fixed angle, or sqrt(maxDistance) inside a loop causes redundant operations on every iteration, whereas hoisting these into pre-computed variables reduces the operation count from O(n) to O(1).

Another key step is rooting out linear searches in your code, especially those hiding inside loops. A linear search as std::find or a manual array scan where works perfectly fine on tiny collections, but in a hot path or with a lot of data it quickly turns into a serious bottleneck. Replacing a linear search with a binary search, using an associative container, or pre-sorting the data and any of these can give you a performance boost.

struct GameObject {
  int id; string name; float x, y, z; bool isActive;

  GameObject(int _id, const string& _name,
             float _x, float _y, float _z, bool _active)
             : id(_id), name(_name),
               x(_x), y(_y), z(_z), isActive(_active) {}
};

// The linear search by the name - O(n)
GameObject* findObjectByName(const string& name) {
  auto it = find_if(objects.begin(), objects.end(),
                    <a href="const GameObject& obj">&name</a>
                    {
                      return obj.name == name;
                    });

  return (it != objects.end()) ? &(*it) : nullptr;
}

Main optimization methods fall into three approaches: hash tables, binary search, and caching. Hash tables (unordered_map) provide average O(1) lookup complexity and are especially effective when access is frequent and keyed by unique identifiers. Pre-building indexes is the best practice: map an ID to an array position or index by a string name, and data access speeds up noticeably. Caching stores the results of expensive operations and returns them quickly on repeated requests. The main thing is to keep the data fresh and invalidate the cache correctly.

A one-time investment in indexing and sorting quickly pays off when you're performing multiple searches. When choosing a data structure, the key is to pick one that fits your specific use case and to be ready to make trade-offs: faster access often requires more memory.

Hash tables are good for frequent key-based lookups, binary search for stable, rarely changing data, and caching for heavy but repeated computations. All of this becomes a big deal inside a game loop, where you might be querying objects hundreds of times per frame. Here's what it looks like in code:

void addObject(const GameObject& obj) {
  size_t index = objects.size();
  objects.push_back(obj);
  idToIndex[obj.id] = index;  // Update indexes
  nameToIndex[obj.name] = index;

  // Active objects cache invalidation
  activeObjectsCacheValid = false;
}

// Search by the name via the hash table - O(1)
GameObject* findObjectByName(const std::string& name) {
  auto it = nameToIndex.find(name);
  if (it != nameToIndex.end())
    return &objects[it->second];

  return nullptr;
}

One key direction is minimizing function-call overhead in critical code paths. A function call generally involves creating a new stack frame, passing parameters, saving register state, and restoring it on return. When the iteration count is high enough, that overhead noticeably hurts performance. It becomes especially painful when functions do almost nothing—the actual work costs about as much as the call overhead itself.

// Unoptimized code
class Vector3D {
  double x, y, z;
public:
  double getX() const { return x; }
  . . .
  double magnitude() const { return sqrt(x*x + y*y + z*z); }
};

// Slow version with multiple function calls
double calculateDistance(const Vector3D& v1, const Vector3D& v2) {
  double sum = 0.0;
  for (int i = 0; i < 1000000; ++i) {
    double dx = v1.getX() - v2.getX();
    double dy = v1.getY() - v2.getY();
    double dz = v1.getZ() - v2.getZ();
    sum += sqrt(dx*dx + dy*dy + dz*dz);
  }

  return sum;
}

Compiler developers are well aware of this and use a variety of optimization techniques to address it. Inlining lets the compiler embed the function body directly at the call site, eliminating the overhead.

Hoisting loop-invariant computations (loop hoisting) prevents repeated execution of identical operations. Merging several simple functions into one reduces the number of jumps and improves data locality in the CPU cache. And yes, the compiler will most likely notice simple getter functions and optimize that fragment but it can't come up with a fundamentally better solution:

class OptimizedVector3D {
  double x, y, z;
public:
  inline double getX() const { return x; }
  . . .

  // Optimized function to evaluate distance
  inline double distanceTo(const OptimizedVector3D& other) const {
    const double dx = x - other.x;
    const double dy = y - other.y;
    const double dz = z - other.z;
    return sqrt(dx*dx + dy*dy + dz*dz);
  }
};

An alternative approach using OptimizedVector3D inlines the getters, which lets the compiler embed their code directly where they're called. It also adds a new method, distanceTo(), which performs all calculations locally without any extra calls. Keep a close eye on memory allocations that sit inside loops or hot functions; they can tank performance. Dynamic memory allocation ranks among the most expensive operations, and its cost multiplies when it shows up frequently in the program's hot paths. We'll dig deeper into how to optimize this kind of code in chapter "The Joy of Programming."

Source-code and function-level optimizations affect performance differently depending on the hardware platform. On high-performance systems—modern consoles and desktops with multi-core CPUs, generous L2/L3 caches, and fast memory—local code tweaks rarely net more than a 2–3% gain and barely move the needle overall. Human mistakes, of course, are another story.

Such improvements rarely make sense for the business: the engineering time they eat up would be far better spent building new features or fixing critical bugs.

The picture flips completely on portable hardware. There, developers deal with ARM chips clocked at 1–3 GHz (versus 4–5 GHz on desktop), L2 caches measured in kilobytes rather than megabytes, and strict power and thermal limits that leave little room to spare. Under those constraints, the same micro-optimizations can deliver double-digit percentage gains, smoother frame pacing, and longer battery life.

Some code examples to make it more tangible:

long unpredictable_branches(const vector<int>& data) {
  long sum = 0;
  for (int val : data) {
    // The data is random, and the branching is unpredictable
    if (val > 0)
      sum += val;
   }

  return sum;
}

--------------------------------------------------------------------------

// Avoid branches through bitwise operations
long branchless_version(const vector<int>& data) {
  long sum = 0;
  for (int val : data) {
    // Use a mask instead of branching
    sum += val & (-(val > 0));
  }

  return sum;
}

Tracking down and landing real micro-optimizations is an art unto itself—you can't do it well without a deep understanding of how the CPU and memory hierarchy actually work. Squeezing a few lines of code down to optimal can eat up days. You're profiling, chasing bottlenecks, staring at cache behavior, wading through assembly, and figuring out exactly how branch prediction works on that one particular architecture.

The payoff from a micro-optimization depends heavily on context: memory access patterns, how your working set maps to the different cache levels, cache-line alignment, how often that code actually runs, and how it interacts with the rest of the system. Many developers treat this as a last resort, preferring changes at other architectural layers and in most cases that's justified.

Game replays (~?%)

Game replays are one of the most powerful debugging tools out there, especially in complex systems with many interacting objects and non-linear logic. A replay is more than a video recording—it's a time-ordered sequence of input data (game commands, events, and states) that the game engine plays back. Its frame-level accuracy lets it reproduce game behavior regardless of the hardware or time of day, which makes it ideal for deterministic debugging. In a nutshell, it's time-travel debugging without the usual baggage: you don't touch the compiler, you don't freeze the entire VM state, and the runtime cost is next to nothing.

Under the hood, a software replay comes down to capturing action points for every object on each game loop iteration: player commands, AI states, network messages, random-number generator updates, and so on. With the right architecture, a replay stays reproducible even months later.

Such a mechanism lets QA or a developer reproduce a bug simply by "scrolling" the match to the right moment. Replays can also be adapted for automated tests, game-scenario simulation, and even AI training. In production, a replay is often more practical and powerful than classic debuggers or logs.

Component isolation (~5%)

Modular component isolation comes down to a simple rule: separate interfaces from implementations, and lean on dependency injection. Well-designed modules interact strictly through defined API boundaries, hiding their internals and keeping subsystems loosely coupled.

An audio system might expose a clean interface PlaySound(), SetVolume() while hiding whether it's backed by DirectSound, OpenAL, or a completely custom pipeline. That kind of isolation lets you swap implementations without touching any client code. It also smooths out porting and platform-specific work: each component can be tuned on its own, with no ripple effects through the rest of the system. The renderer can have separate backends for DirectX, Vulkan, Metal, or OpenGL, selected at startup, leaving the gameplay code completely untouched. The same goes for the input system: it can switch between keyboard/mouse, gamepad, touch, or VR controllers while the game code sees only a uniform interface. All of this enables platform-specific solutions without merge conflicts, lets developers test the performance of individual components in isolation, and makes it possible to change one part without threatening the stability of the whole system.

Specific low-level optimizations (<3%)

Many developers fall into the trap of thinking low-level optimization calls for the heavy artillery—inline assembly, fancy algorithms, a full SIMD rewrite. It usually doesn't; in reality, many optimizations turn out to be fairly simple and intuitive. Clean code tends to be fast to compilers and optimizers like it that way. But that's not always the case.

Other (~10%)

So what does this slice of development actually look like? Normally it means solid build pipelines: a build reaches QA within an hour of the commit and, if something's broken, lands back in the author's lap within two. A healthy setup includes good debuggers, replays, and modern game development tools like behavior trees (BT), visual scripts (VS), blueprints, and animation scripts (AS). These systems are notoriously hard to debug under a debugger, and the bugs they produce have a nasty habit of being unreproducible 99% of the time. Of course, a lot hinges on the skill of your QA team. These improvements may not directly affect the game's runtime performance, but they help identify and resolve issues faster. And when a developer builds a feature instead of fixing a bug, that's a direct win for the project.

Benchmarks

Benchmarks are the cornerstone of any optimization approach. You can't improve what you can't measure. A good benchmark acts as a compass in the vast sea of optimization, giving you immediate feedback on the impact of every change. At its core, a benchmark is an execution scenario that reproduces a specific workload and serves as a reference point for quantitative comparison of different code versions and their performance.

So, a solid benchmark should satisfy four critical requirements:

Reproducibility, a fundamental property that gets overlooked surprisingly often. Repeated runs under the same configuration should produce statistically consistent results, although individual outliers can occur (even fairly large ones). Fixed input data, deterministic behavior for random values through a predefined seed, stable system conditions, and strong isolation from external influences such as network activity or background processes all contribute to reproducibility.
Speed test, a practical requirement for maximizing development efficiency. A well-designed benchmark rarely takes more than a few dozen seconds to run, letting developers iterate on optimizations quickly without sitting around waiting.
Representativeness or realistic behavior, achieved by modeling real gameplay scenarios with CPU, GPU, memory, and I/O usage patterns that closely match actual game behavior. A benchmark should reproduce real workloads such as physics simulations, rendering tasks, or AI-intensive calculations. Avoid purely synthetic tests that have little connection to the engine's real architecture.
Bench sensitivity, which ensures the benchmark can detect both performance improvements and regressions. Statistical analysis needs at least 10–20 runs to mean anything. A good benchmark shows a clear difference (typically 5–10%) after significant code changes while staying steady through cosmetic tweaks that don't affect performance. For example, you might notice the frame rate dropping in a particular game scene. Before starting any optimization work, set up a reproducible test case: pin down the exact spot where the problem shows up and make sure you can get to it quickly. This lets you take repeated measurements under identical conditions. In reality, though, that isn't always feasible, so developers often build a dedicated benchmark scene or test mode with strictly deterministic behavior. Each run then produces comparable results, making performance measurements far more trustworthy.

The whole point of benchmarking is to put a number on the comparison between the original and the optimized version of your code. Whenever possible, start with measurements so you can back up any claimed improvement with actual numbers rather than intuition. Despite its apparent simplicity, building good benchmarks hides plenty of pitfalls. One of the most common mistakes is measuring only hot runs: developers discard the first iterations to avoid warm-up effects or cache population, but forget that real games hit cold starts and cold data just as often as hot ones.

Automating benchmarks through CI/CD catches performance regressions early, while graphing the results makes it much easier to spot long-term trends and correlations between different performance metrics.

Measurements

The next step in optimization involves collecting and analyzing performance metrics to pinpoint bottlenecks. Every change should improve performance while consuming as little time and effort as possible—in other words, it should deliver a strong return on investment (ROI). Not every result will be a clear win, but even failed experiments help reveal the most promising direction for the next step.

Proper diagnostics ensure that developers address an actual performance issue rather than a random piece of code that barely affects overall efficiency. Metrics, profiles, and logs are the main sources of information here, helping teams avoid blind changes and unnecessary rounds of optimization.

The approach to optimization mirrors how engineers analyze any system: start with a high-level view, then gradually narrow the focus to specific cases. At the top level, the goal is to identify the primary performance constraint—whether it's the CPU, GPU, or memory. In most cases that actually need fixing, the bottleneck ultimately traces back to a particular module or code fragment, which narrows it down to the level of algorithms and data structures. To track down these issues, developers rely on profilers, system monitors, tracing tools, and engine performance metrics. These tools help identify hot spots—functions or routines that consume a significant share of CPU time, GPU resources, or memory. This is where optimization reaches the source-code level.

When analyzing performance, start by evaluating CPU and GPU usage with general-purpose monitoring tools. If the GPU isn't under heavy load, a profiler can help measure how much time the CPU spends updating and processing game logic. Identifying issues at the high level narrows the scope of analysis and lets developers focus optimization efforts on a specific area.

At the same time, it's important to remember that a performance issue rarely comes down to a single root cause. A game consists of countless micro-operations, and bottlenecks often emerge from the combined effect of several factors. At the instruction level, the issue may stem from a long-running call that leaves the processor sitting idle while it waits for data. At the GPU level, it might be an imbalance in how rendering commands are processed.

These may look like two separate problems, but fixing one often affects the other. By looking across different levels of analysis, from low-level details to high-level system behavior, you can identify the component that's actually constraining performance the most and put your resources where they matter. Always start with the big picture, then gradually drill down into specific bottlenecks. Combine multiple tools and metrics to track down and address real issues rather than rushing to fix the first suspicious symptom you run into. Building a list of potential problem areas can help, as it often points the way toward the actual source of the issue.

Finally, effective optimization has to factor in the cost of implementation. In some cases, removing a particular bottleneck may take substantial effort while delivering little gain. When that happens, it often makes more sense to focus elsewhere. The impact-to-cost ratio can serve as an optimization metric that helps teams avoid getting stuck obsessing over micro-optimizations. As a result, optimization stops being a collection of isolated tweaks and becomes a structured process that improves the efficiency of the whole system.

Changes and engineering intuition

Once you've gathered enough data and identified the bottleneck limiting performance, set those results aside and analyze everything again from scratch, this time deliberately excluding that bottleneck.

This technique is known as hotspot avoidance. The idea is to focus first on how the other system components behave, rather than on the hotspot you've already found (in about 80% of cases, there won't be any other significant bottlenecks). This approach can reveal hidden bottlenecks that stay invisible when a dominant hotspot monopolizes the profiler. It also gives you a fuller picture of how the workload distributes across the components.

The real value of this method becomes clearer once you've built up extensive experience optimizing different systems. By eliminating the main bottleneck, you can spot the points that, combined, can yield a significant performance gain, or that affect the hotspot itself in ways you wouldn't otherwise notice. The technique also simplifies the analysis of complex systems, where hidden dependencies often produce counterintuitive behavior (this is where so-called engineering intuition kicks in).

At that point, you can start making changes. They may involve modifying algorithms, optimizing data structures, improving memory access patterns, or, in extreme cases, rewriting an entire subsystem. Even experienced optimization engineers rarely land on the best solution on the first try. Most end up testing several hypotheses and trying out multiple approaches before settling on a final implementation. This is where the insights from hotspot avoidance prove especially valuable.

Once the changes are in place, measure performance again using benchmarks and profilers. Without measurement, there's no reliable way to tell whether fixing a bottleneck actually helped, or whether the real issue was sitting elsewhere. Systematic measurement not only helps identify the true causes of performance issues but also builds experience and sharpens what many engineers call engineering intuition—the ability to spot similar issues faster and more accurately on future projects. Some of my colleagues, who spent years working on game engines, could often pinpoint a problem just by examining logs and a profiler snapshot, without even looking at the source code. More often than not, their read on which subsystem or code fragment to modify turned out to be right. That's exactly the kind of intuition I mean.

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.

All parts

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

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

Game++. Part 1.3: Game engine architectures

Game++. Part 1.4: Game engine architectures

C++: Write, shorten, optimize

Unicorn Developer — Thu, 23 Jul 2026 14:01:55 +0000

I stumble upon a C++ function that will be a really illustrative example of how refactoring can both shorten and optimize code. Today, we'll need to dust off our human brains in the era of vibe coding and recall what it's like to know what the good is and what the bad is—after all, someone has to do it.

The code snippet below from the vibe-coded project VibeTensor. I like exploring such projects as if I were a naturalist studying a new ecosystem—you can meet with my "field reports" here and there. So, I'm very curious to discover the genesis of new defects and flaws in code. Why? It helps us better understand and describe the challenges code can face in the GenAI era.

One of my discoveries is code bloat that hurts readability and compilers' optimization. The following example showcases it in all its beauty.

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

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

It may seem that code size and performance are not so critical because they're used in tests.

However, the code is duplicated across nine files, and ideally, that shouldn't happen at all, but if code is going to spread like this, it should at least stay compact.

Also, we shouldn't forget that the generated C++ code must be optimized because the C++'s main purpose is to create highly efficient apps. In this case, we have to deal only with the slow test, but in another context, such patterns would significantly downgrade app performance and the negative impact would only grow as more flawed generated code accumulates over time.

Slow C++ code goes against the idea of this programming language. That's why it's still a must-have to enhance the expertise in determining whether the code is well-written and how it can be refined, shortened, or optimized. Advanced knowledge can also help in regenerating code with better prompts.

So, let's practice and do some refactoring. Let's start with this code fragment:

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

All the array elements are multiplied. If it encounters 0, the loop terminates to avoid unnecessarily processing the remaining array elements because it'll still set the result to zero.

The any_zero flag resets the variable that stores the product, but we can go easier:

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

When we encounter 0, ne will be set to 0 and the loop will end. We have another place for simplification: modern processors perform multiplication operations quickly, so we can do the multiplication first and then check it.

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

The code's functionality hasn't changed, but it's become shorter and, in my opinion, even easier to understand.

If we already know that the array is small or that performance isn't critical (for example, because the function is called infrequently), we could simplify it even further:

int64_t ne = 1;
for (auto s : sizes) {
  ne *= s;
}

Let's not think about that, since further actions make the loop be absorbed by another one.

Now let's go back to the beginning of the function.

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

The static_cast makes code clunky. The first type casting is needed so that certain compilers or static analyzers don't flag odd arithmetic operations.

std::ptrdiff_t i = static_cast<std::ptrdiff_t>(nd) - 1;

Let's consider what would happen if we removed the static_cast and the input array turned out to be empty:

If the array is empty, then nd = 0;
If we subtract one from an unsigned zero, we get SIZE_MAX, that is, a very large positive unsigned number.
The SIZE_MAX of thesize_t type is implicitly converted to ptrdiff_t and stored in the i variable. It turns out that i = -1 works as intended. But this is exactly where warnings may be issued. We initialize ptrdiff_t with a number that is larger than the range of the largest number it can hold. Before C++20, the result was implementation-defined. Since C++20, the behavior is well-defined.

As a result, it'd be better to leave the first static_cast as is. We can't say the same about the rest. They make no sense at all.

In the vector class, the [] operator takes an argument of the size_type type (typically an alias of size_t). The i variable value will automatically be converted to size_t, and there's nothing unsafe or suspicious about it. The explicit casts only add visual noise, so they're better removed.

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

You've taken the first step. But can we simplify this line even further? Let's see—I'd like to write something like this:

for (auto sz : std::ranges::views::reverse(sizes)) {
  strides[???? i ????] = acc;
  acc *= (sz == 0 ? 1 : sz);
}

You still need the i variable to iterate through the strides array from the end, so we can't eliminate i completely. But we can do something like that:

int64_t acc = 1;
size_t i = nd;
for (auto sz : std::ranges::views::reverse(sizes)) {
  strides[--i] = acc;
  acc *= (sz == 0 ? 1 : sz);
}

To be honest, I don't like that --i has made the code more complicated and forces us to pause and realize why the variable is decremented in the beginning and then is used to access an array element.

Okay, there is less code now, and it's easier to scan through it quickly, so half the work is done. But the code is still ultimately hard to read—it's neither clearer nor intrinsically harder.

Let's take a look at the result.

static TensorImpl make_contiguous_tensor(const std::vector<int64_t>& sizes) {
  const std::size_t nd = sizes.size();
  std::vector<int64_t> strides(nd, 0);
  int64_t acc = 1;
  size_t i = nd;
  for (auto sz : std::ranges::views::reverse(sizes)) {
    strides[--i] = acc;
    acc *= (sz == 0 ? 1 : sz);
  }

  int64_t ne = 1;

  for (auto s : sizes) {
    ne *= s;
    if (s == 0) {
      break;
    }
  }
  ....
}

Now that there is less code, it becomes clear that the second loop is redundant. In the first loop, we iterate through all the elements. So why not multiply them right away?

static TensorImpl make_contiguous_tensor(const std::vector<int64_t>& sizes) {
  const std::size_t nd = sizes.size();
  std::vector<int64_t> strides(nd, 0);
  int64_t acc = 1;
  size_t i = nd;
  int64_t ne = 1;
  for (auto sz : std::ranges::views::reverse(sizes)) {
    strides[--i] = acc;
    acc *= (sz == 0 ? 1 : sz);
    ne *= sz;
  }
  ....
}

Oh, it's an absolute beauty. It's not a big deal that we multiply all the elements together, even though one of them might be zero. Microprocessors are multiplying rapidly these days. You could lose more by re-accessing all the elements in the second loop.

What else is left? We don't need to initialize the strides container with zeros. All of its elements will be overwritten anyway.

std::vector<int64_t> strides(nd, 0); // delete the second argument

I think that's all. We can also make one more small change: remove the nd variable. It's not needed here or in the code that follows.

As a result, we have:

static TensorImpl make_contiguous_tensor(const std::vector<int64_t>& sizes) {
  auto q = sizes.size();
  std::vector<int64_t> strides(q);
  int64_t acc = 1;
  int64_t ne = 1;
  for (auto sz : std::ranges::views::reverse(sizes)) {
    strides[--q] = acc;
    acc *= (sz == 0 ? 1 : sz);
    ne *= sz;
  }
  ....
}

Hooray! We cut the code in half: from 20 lines down to just 9!

What's inside the assembly code?

The function is shorter now, but does that also improve performance? Yes! Let's take a look at the main section of the assembly code for the original function version.

Clang is used with the -O2 option:

.LBB1_7:
        mov     rax, rsi
        mov     qword ptr [rbx + 8*r12 - 16], rsi
        mov     rsi, qword ptr [r13 + 8*r12 - 16]
        cmp     rsi, 1
        adc     rsi, 0
        imul    rsi, rax
        dec     r12
        cmp     r12, 1
        ja      .LBB1_7
        mov     r12d, 1
        cmp     rbp, r13
        je      .LBB1_9
.LBB1_4:
        mov     rax, qword ptr [r13]
        test    rax, rax
        je      .LBB1_5
        imul    r12, rax
        add     r13, 8
        cmp     r13, rbp
        jne     .LBB1_4
        jmp     .LBB1_9

We can see a rather verbose assembly code with two loops. Now let's compare it with the assembly generated for the refactored version.

.LBB1_10:
        mov     rcx, rsi
        mov     rdx, qword ptr [rbp - 8]
        add     rbp, -8
        mov     qword ptr [rax], rsi
        cmp     rdx, 1
        mov     rsi, rdx
        adc     rsi, 0
        imul    rsi, rcx
        imul    r12, rdx
        add     rax, -8
        cmp     rbp, r13
        jne     .LBB1_10

Oh, that's pure beauty. One loop. Compact and efficient. Wow!

To those who aren't very familiar with the assembly language, it might seem strange that there isn't a conditional jump to implement this: sz == 0 ? 1 : sz.

Here's how it works
The value of acc is stored in the RSI register. We'll need a copy of this value later, so it's stored in the RCX register.

mov     rcx, rsi

The RBP register contains the address used to iterate through the elements of the sizes array in reverse order. Here, we load the element into the sz variable (RDX) and shift the iterator by 8 bytes (the size of the int64_t element) to the left.

mov     rdx, qword ptr [rbp - 8]
add     rbp, -8

RSI is acc. Let's put the register in the strides array. RAX holds the element address. The jump to the previous element will be executed below (see add rax, -8).

mov     qword ptr [rax], rsi

Now, we've reached the cherry on top: acc *= (sz == 0 ? 1 : sz) is executed and the RDX register(sz variable) is compared with 1.

cmp     rdx, 1   // CF = is moved when sz - 1

How does it work?

1 is subtracted from RDX. If a jump occurs, the carry flag (CF) is set. This happens only when CF = 1 if RDX is 0.

This is acc = sz. We overwrote the variable's value, but that's okay because we have a copy of it in RCX.

mov     rsi, rdx // acc = sz

If sz was 0, let's change it to 1. To do this, let's add the CF carry flag. If sz is not 0, then the carry flag is 0, and nothing will change. That's how the compiler avoided the conditional jump.

adc     rsi, 0   // acc = acc + 0 + CF

All that's left is to perform two multiplications, decrement RAX, and continue the loop.

imul    rsi, rcx // acc = acc * {ACC copy in RCS register}
imul    r12, rdx // ne = ne * sz
add     rax, -8
cmp     rbp, r13 // Do we reach the beginning of strides?
jne     .LBB1_10 // If no, we'll get goto LBB1_10

Another way

Do we have another way? Yes, we have. I don't know whether I think about it or not. Unfortunately, after finishing my own refactoring, I made the mistake of immediately asking AI for alternative solutions.

DeepSeek suggestions weren't any better, and some were even worse than the original. For example, it optimized one of the code implementations by reversing the array.

// Wrap out strides
std::reverse(strides.begin(), strides.end());

But Claude Opus came up with an unusual implementation. It was noticed that we don't actually need two independent sequences of multiplications.

If all elements of the input array are non-zero, then at the end of the loop, acc == ne. And if even one element was zero, we can simply set ne to zero at the end. We return to the any_zero flag again, but in a smarter way. Using this idea, we can write the following code:

static TensorImpl make_contiguous_tensor(const std::vector<int64_t>& sizes) {
  auto q = sizes.size();
  std::vector<int64_t> strides(q);
  int64_t acc = 1;
  bool any_zero = false;
  for (auto sz : std::ranges::views::reverse(sizes)) {
    strides[--q] = acc;
    acc *= (sz == 0 ? 1 : sz);
    any_zero |= sz == 0;
  }
  const int64_t ne = any_zero ? 0 : acc;
  ....
}

Assembly code

.LBB1_7:
        mov     rdx, rsi
        mov     rsi, qword ptr [r13 - 8]
        add     r13, -8
        mov     qword ptr [rcx], rdx
        test    rsi, rsi
        sete    dil
        cmp     rsi, 1
        adc     rsi, 0
        imul    rsi, rdx
        or      al, dil
        add     rcx, -8
        cmp     r13, rbp
        jne     .LBB1_7
        xor     r13d, r13d
        test    al, 1
        cmove   r13, rsi
        mov     r14, r8

Will code that performs half as many multiplications run faster? My prediction—not necessarily. The processor can perform two unrelated multiplications simultaneously on different pipelines. I'm willing to bet that my version and Claude's version will run at almost the same speed.

Performance measurement

Let's see how these implementations compare in reality. Designing a fair benchmark took a bit of effort. First, I had to ensure the input data couldn't overflow a 64-bit signed integer, since signed overflow is undefined behavior and would invalidate the measurements. Second, to make the contest fair, the test cases alternated between arrays with and without zero elements. Finally, the input arrays had varying lengths.

I'm not claiming that the measurements are rigorous, but they represent a general idea. The speed of the first original algorithm is taken as the baseline. I used Clang with the -O2 and -m64 options.

The original version with two loops: 1.
My version with a single loop: 0.88.
The Claude version with a single multiplication: 0.92.

The refactoring improved performance by about 10% on average. I was actually hoping for a 20–30% speedup, but 10% is still a nice result—especially considering that it came from simplifying the code rather than making it more complicated.

Wrap-up

Let's stop our little refactoring adventure here. Was it worth it?

From the perspective of improving this particular piece of code, I'd say no. Tests are generated. It's not critical that code is longer and slower than it could be.

It doesn't matter whether code is written by a human or generated by AI. One thing remains constant, someone must recognize what bad is and what good is. There must be experts who can spot the difference. Is the code good? Is it bad? Is the code fast? Is it secure?

Some people can accept just the fact that the code works—and who cares what's inside it. In some cases—for example, for building a prototype—this is reasonable. However, those who aren't interested in architecture, optimization, or security most likely simply don't see or understand the whole picture of developing and maintaining large software products. So, I think we'll likely see a lot of drawbacks on this topic.

AI is a powerful tool, but it's not a magic wand. When Claude suggested an alternative version of the algorithm to me, it was a good example of how AI can be used for research and to enhance human capabilities. But it can just as easily cause harm if used carelessly.

If you want to continue improving your skills as a C++ specialist and create reliable, secure software, I suggest you check out these useful e-books and webinars on our website:

E-books & Webinars

Let's make a programming language. AST—Key points

Unicorn Developer — Wed, 22 Jul 2026 12:50:23 +0000

In this part, we continue the development of a toy programming language by introducing the Abstract Syntax Tree (AST), the data structure that represents the hierarchical structure of source code after parsing.

About the speaker

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

The foundation

Each language construct corresponds to an AST node, while collections of nodes, such as function bodies or parameter lists, are represented by dedicated list nodes. Yuri explains the core node types, including literals, identifiers, unary and binary expressions, assignments, function calls, declarations, statements, and error nodes.

Error nodes allow parsing to continue after syntax errors, enabling the compiler to collect multiple errors instead of stopping at the first one. Invalid nodes propagate their state upward so the entire program can be marked invalid before evaluation.

Let's grow our tree!

A central component of the implementation is the AST builder, which owns every created node and manages memory automatically. As the parser recognizes grammar rules, it instructs the builder to create nodes. Terminal nodes are stored in an internal state, while compound nodes consume previously created child nodes from that state and combine them into larger structures until the root node of the program is produced.

Traversing the Tree

The second half of the talk focuses on traversing the AST with a visitor. The visitor performs a depth-first traversal using preview and visit functions. Preview executes when entering a node and can decide whether to traverse its children, while visit runs after returning from them. This design allows specialized visitors to process only the node types they need.

As an example, Yuri demonstrates an AST printer that uses the visitor to produce a tree-like representation of the program structure, concluding with a preview of future topics covering variables, types, semantics, functions, and evaluation.

Want more?

If you want to watch other talks or see the whole episode, follow this link.

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

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

See ya!

PVS-Studio brings Unreal Engine support to Team licenses

Unicorn Developer — Mon, 20 Jul 2026 12:58:32 +0000

Good news for Unreal Engine developers: we've made PVS-Studio more accessible! You can now analyze UE projects in PVS-Studio with a Team license, not just an Enterprise license. We'll explain below why we changed our licensing model and what it means for small and mid-sized game studios.

What is PVS-Studio?

In case you haven't heard of us yet: PVS-Studio is a static analyzer for C, C++, C#, and Java code (+ JavaScript/TypeScript and Go in the upcoming August release). PVS-Studio is a tool that automatically checks your project's code for potential errors, security vulnerabilities, and optimization opportunities without executing the code itself.

If you'd like to learn more about the analyzer's capabilities and use cases, check out our overview article.

PVS-Studio is now more accessible to Unreal Engine developers

Game projects continue to grow in both scale and complexity. A modern game can contain millions of code lines, hundreds of modules, and countless interconnected systems. Even experienced teams may miss bugs that slip past the compiler and code review.

At the same time, a large part of the industry consists of indie and AA studios. Despite having smaller budgets and fewer developers, such teams tackle complex engineering challenges and care just as much about delivering high-quality products.

PVS-Studio 7.43, released in June 2026, introduced an important change: Unreal Engine project analysis is now available with the Team license instead of being limited to Enterprise. This makes the tool more affordable for small and mid-sized game studios and lowers the barrier to adopting static analysis as part of their daily development workflow.

Why did we make this change?

Unreal Engine has long been the go-to option for teams of all sizes, from AAA studios and AA developers to indie teams and solo creators. For many of them, the Enterprise license was excessive, especially when working within a tight budget and carefully selecting development tools.

According to the 2026 State of the Game Industry report, Unreal Engine is now the primary engine for the largest percentage of game developers, with approximately 42% of respondents using it as their main engine. It's particularly popular among AA studios, where the engine is used even more broadly than in the AAA segment.

Figure 1—GDC 2026 State of the Game Industry Report: What game engine do you primarily use for game development?

Like larger studios, these teams face technical challenges such as complex game logic, ever-growing codebases, third-party integrations, platform-specific issues, and hard-to-reproduce bugs. The difference is that they usually have fewer resources available for extensive debugging, manual code reviews, and dedicated QA workflows.

QA often takes a back seat while the team focuses on building gameplay features. As a result, bugs negatively impact the player experience and damage the game's reputation right at release. In smaller studios, developers often have to handle testing themselves because the team isn't big enough and the budget may not allow for hiring dedicated QA specialists.

The Team license is designed with such teams in mind. By adding Unreal Engine support at this licensing tier, we've made static analysis more accessible where it can have the greatest impact: in teams where catching bugs early saves time, money, and effort while helping developers stay focused on creating great games.

How bugs affect development pace

The cost of an error

Players pay especially close attention to the quality of a game during the first few days after its launch. If bugs, crashes, or critical failures arise during that period, the team must immediately shift its focus to analyzing feedback, deploying hotfixes, and stabilizing the game. This means investing time and money on work that is rarely part of the intended project plan.

High-profile releases such as Assassin's Creed Unity and Cyberpunk 2077 demonstrate that technical issues at launch can lead to months of post-release fixes. Teams with limited resources may find it even more challenging to recover from a rocky launch.

In reality, the benefits of catching bugs early extend beyond saving money. Understanding and fixing the issue is usually easier when the code is still fresh in the developer's mind. If the bug surfaces much later, the team has to reconstruct the original context, untangle dependencies, and stop working on other projects to investigate it.

Static analysis naturally fits into everyday development workflows, including local development, builds, and CI. It helps developers spot suspicious code before fixes require lengthy investigations, repeated testing, or urgent patches.

If you'd like to learn more, check out our article on how static analysis affects the cost of fixing errors throughout a project's lifecycle.

What does this mean for a team?

Based on discussions within the community, it's clear that most people don't pursue a career in game development to spend their days shipping emergency patches or tracking down typos in legacy code. They'd rather focus on designing gameplay mechanics, building systems, creating content, and making their game better.

The static analyzer doesn't replace developers or make decisions for the team. Its job is much simpler: it highlights potential issues in code and helping teams find bugs earlier with less effort.

For the team, this means a more streamlined workflow with fewer interruptions and more time to focus on tasks that advance the project.

What does PVS-Studio offer for Unreal Engine projects?

Unreal Engine has its own architecture, type system, coding conventions, and internal mechanisms. So, the key to a thorough analysis is considering the engine specifics instead of relying solely on general C++ checks.

We continue to expand Unreal Engine support in PVS-Studio, including in collaboration with Epic Games. It helps us better account for UE-specific behavior, improve our integrations, and respond more quickly to issues developers encounter when using the analyzer with real-world Unreal Engine projects.

This translates into a smoother out-of-the-box experience for teams working with Unreal Engine:

Annotations for Unreal Engine code

PVS-Studio includes built-in annotations for Unreal Engine. They help the analyzer interpret code more accurately, account for engine-specific behavior, and reduce false positives without requiring extensive manual configuration.

UE-specific diagnostic rules

The analyzer also includes diagnostic rules specifically designed for Unreal Engine projects. They help detect issues stemming from UE-specific coding patterns, engine conventions, and the object lifecycle of the engine. Here are a couple of examples:

V1100: Declaring a pointer to a type derived from 'UObject' in a class that is not derived from 'UObject' is dangerous.
V1102: Violation of naming conventions may cause Unreal Header Tool to work incorrectly.

Integration with the Unreal Engine toolchain

Our goal is to support the workflows and tools that Unreal Engine developers already rely on. This way, introducing static analysis won't disrupt an established development process.

Run PVS-Studio in Unreal Build Tool

Starting with Unreal Engine 4.17, you can run PVS-Studio directly through Unreal Build Tool. This makes it easy to integrate the analyzer into your existing build pipeline and use it as part of your regular development workflow.

Support for multiple Unreal Engine versions

PVS-Studio supports both legacy and current Unreal Engine releases. This is especially important for teams that can't immediately migrate to the latest engine version and need to continue developing projects using their current version.

Integration with Unreal Build Accelerator, Horde, and SN-DBS

For large projects and CI pipelines, analysis speed and seamless integration with existing build infrastructure are essential. PVS-Studio is compatible with Unreal Build Accelerator, Horde, and SN-DBS. This streamlines the integration of static analysis into existing distributed build and code check workflows.

A comprehensive set of diagnostic rules for everyday C++ development

In addition to providing diagnostic rules specific to Unreal Engine, PVS-Studio detects a wide range of issues that can affect any C++ codebase. For example, it can identify:

memory and resource management issues: memory leaks (V773), use-after-free bugs (V774), and double resource deallocation (V586);
uses of uninitialized data: in local variables, class members, and constructors (V614, V730, V670);
object lifetime and reference issues: dangling references, incorrect handling of temporary objects, string_view, lambda, and objects after std::move (V758, V1017, V1047, V1030);
logic errors in conditions and expressions: conditions that always evaluate to true or false, suspicious comparisons, and incorrect operators (V547, V517, V709, V564);
copy-paste errors and other human mistakes: duplicated code fragments, variable name typos, and suspicious inconsistencies between similar checks (V778, V722, V1013, V524);
integer overflows, unsafe conversions, and signedness issues (V1028, V1083, V1112, V1029);
issues with loops, indexing, and array bounds (V557, V621, V776).

Fast fixes for issues and false positives

Working effectively with Unreal Engine requires a stable and reliable tool. That's why we focus on both adding new features and refining existing integrations. We're constantly working to fix reported issues, improve compatibility, and reduce the number of false positives.

Our collaboration with Epic Games plays an important role in this effort. It helps us respond more quickly to changes in the Unreal Engine ecosystem and adapt the analyzer to the real-world needs of developers.

To learn more about our collaboration, check out the article on the Epic Games website.

Ready to give it a try?

Starting with PVS-Studio 7.43, you can analyze Unreal Engine projects under the Team license.

If you use Unreal Engine for development and have considered trying PVS-Studio, now's the perfect time to run the analyzer on your project. If you have any questions about integration or configuration, our support team will be happy to help you.

You can get a trial version here.

Stay creative, and we'll be there to help protect your code from bugs, vulnerabilities, and typos with PVS-Studio.

One mistake no one has ever made. Right?

Unicorn Developer — Thu, 16 Jul 2026 14:02:41 +0000

As early as your freshman year of college—or even earlier—you might have realized that writing arr[len(arr)] is a bad idea. Surely, no one could get that wrong, right? We thought the same thing, until we checked 1,000 projects.

A quick explanation of the error, just in case

Any Go developer knows that the built-in len() function takes a value and returns its length based on the value's type.

Let's check the documentation and take a closer look at a function signature:

func len(v Type) int

The built-in len function returns the length of v based on the type of the passed value:

Array: the number of elements in v.
Pointer to array: the number of elements in *v (even if v is nil).
Slice, or map: the number of elements in v; if v is nil, len(v) is zero.
String: the number of bytes in v.
Channel: the number of elements queued (unread) in the channel buffer; if v is nil, len(v) is zero.

Look at this simple example:

func SimpleExample(arr []int) {
  _ = arr[len(arr)]
}

Collection indices always start at 0. So, for a slice of the n length, the valid indices range from 0 to n – 1. Then len(arr) returns n. As a result, accessing arr[len(arr)] always leads to a program panic.

What's V8031, and how did we discover it?

First, a quick note: in case you didn't know, we're developing PVS-Studio, a static analyzer for C, C++, C#, and Java code. The early access program for the new Go and JS/TS analyzers just ended. We're currently preparing them for the release, which is scheduled for August. Around the same time, the early access program for PVS-Studio Atlas—a team solution for managing code analysis results—will launch. Stay tuned for updates.

Now back to V8031. It's a diagnostic rule for the Go analyzer. We didn't expect it to deliver such good results when we were working on it. We even assumed it might not find anything. We thought, "What if this is a made-up error that can be spotted in any review or test?" From our experience, though, we knew there could be dozens of such errors that are easy to spot but often overlooked due to exhaustion, carelessness, or a lack of effort.

Implementing the diagnostic rule was easy: it's built entirely on AST and uses as little of our own code as possible beyond what Go's built-in analysis tools provide. Feel free to create your own diagnostic rules, by the way. You might want to start with our introductory article, "How to create your own Go static analyzer?"

The next step is testing. In our team, it consists of three stages:

Unit testing;
Running a diagnostic rule on our collection of GitHub projects;
Running a diagnostic rule on the 1,000 most popular Go projects (selected by number of stars).

Right now, we'll focus on the third stage. We were surprised by the results as soon as we got them. Let's take a look at them.

The results

In our articles, we usually describe errors and explain possible ways to fix them. We won't do that here since all the code snippets would have the same description as the one at the beginning of the article.

Project No. 1

bfe is a modern load balancer used by Baidu.

type BasicLitList []*BasicLit
....
func (b BasicLitList) End() token.Pos {
  return b[len(b)].End()
}

PVS-Studio warning: V8031 Using the call of the 'len' function as index will cause off-by-one error. Consider using 'len(b) - 1' instead. ast.go 138

Project No. 2

Ferret is a programmable data extraction and automation tool for developers.

func (vec *Vector) Push(value core.Value) *Vector {
  slice := vec.getCurrentSlice()
  slice[len(slice)] = value

  return vec
}

PVS-Studio warning: V8031 Using the call of the 'len' function as index will cause off-by-one error. Consider using 'len(slice) - 1' instead. vector.go 28

Project No. 3

fq is a tool, language, and set of decoders for working with binary and text formats.

var blockFns = map[uint64]func(d *decode.D, dc *decodeContext){
  ....
  blockTypeInterfaceDescription: func(d *decode.D, dc *decodeContext) {
    typ := d.FieldU16("link_type", format.LinkTypeMap)
    d.FieldU16("reserved")
    d.FieldU32("snap_len")
    d.FieldArray("options", ....)

  dc.interfaceTypes[len(dc.interfaceTypes)] = int(typ)
  },
  ....
}

PVS-Studio warning: V8031 Using the call of the 'len' function as index will cause off-by-one error. Consider using 'len(dc.interfaceTypes) - 1' instead. pcapng.go 234

Project No. 4

Incus is a modern container management system and virtual machine manager.

func qemuRawCfgOverride(conf []cfg.Section, confOverride string) (....) {
  ....
  content := &sectionContent{
    comment: sec.Comment,
    entries: entries,
  }

  indexedSection[len(indexedSection)] = content
  orderedSections = append(orderedSections, section{
    name:    sec.Name,
    content: content,
  })
  ....
}

PVS-Studio warning: V8031 Using the call of the 'len' function as index will cause off-by-one error. Consider using 'len(indexedSection) - 1' instead. driver_qemu_config_override.go 50

We spotted two such errors in this project:

func (f *heartbeatFixture) node() (*state.State, *cluster.Gateway, string) {
  ....
  f.gateways[len(f.gateways)] = gateway
  f.states[gateway] = state
  f.servers[gateway] = server

  return state, gateway, address
}

V8031 Using the call of the 'len' function as index will cause off-by-one error. Consider using 'len(f.gateways) - 1' instead. heartbeat_test.go 253

We've encountered some errors multiple times in other projects. The reason for this was that some Project 1 included some other Project 2 as a dependency. So, it's fair to say that the errors are piling up.

Let's summarize

We wanted to share these exciting results with you. Although unlikely, this error may lurk in your own project. Not long ago, we discussed another interesting error in the article Does the operator ^ represent exponentiation or exclusion?. And to ensure your project's code is clean, you can use PVS-Studio static analyzer.

Happy coding!

History of JavaScript: Browser wars, ECMAScript, Node.js, TypeScript, and React

Unicorn Developer — Thu, 09 Jul 2026 12:44:06 +0000

It only took ten days to develop the language that powers the web. This article tells the story of JavaScript and the tools that helped shape it.

1995. The birth of a legend

The idea for JavaScript was born at Netscape. At the time, web pages consisted almost entirely of HTML, and Netscape wanted to make them more interactive.

The first step in that direction was licensing Java for use in the Netscape browser. However, Java's complexity proved challenging for web designers.

Brendan Eich was then tasked with creating a programming language that wasn't too complex and could be embedded directly into HTML pages. Eventually, Marc Andreessen, co-founder of Netscape Communications, and Bill Joy, co-founder of Sun Microsystems, also contributed to the language development. To meet the deadline for the Netscape browser release, the companies agreed to collaborate on the language.

During its development, the language changed its name several times. For example, the first version Eich created in just ten days was called Mocha. It was then renamed to LiveScript. The final name was chosen because the word Java was already popular and well-known.

JavaScript was first announced shortly before the second beta release of Netscape Navigator. Meanwhile, Netscape announced that 28 leading IT companies planned to incorporate JavaScript into their future products.

JavaScript 1.0 was released in 1996 alongside Netscape Navigator 2.

1997-1999. ECMAScript

In 1996, Microsoft also released JScript as part of Internet Explorer 3, which was an open-source implementation of JavaScript for Windows. By the way, the name was changed to avoid negotiating trademark rights for Java with Sun Microsystems.

To eliminate browser incompatibilities caused by different implementations, Netscape handed the JavaScript specification over to the ECMA international organization.

So, the ECMA-262 specification was created. The language got the name ECMAScript because JavaScript was already trademarked. Around the same time, the TC39 technical committee was formed, bringing together representatives from Netscape, Microsoft, Sun Microsystems, and other companies. It still exists today, continuing to define the evolution of ECMAScript.

The ECMAScript 2 specification was released in September 1998. Although it didn't introduce any new features, it laid the groundwork for all future changes.

ECMAScript 3 was released in 1999, introducing several new language capabilities, including regular expressions, exception handling, the switch-case statement, and the do-while loop variant.

2001. The end of the first browser war

The first major rivalry among web browser companies began in 1995.

At the time, Netscape Navigator was the most well-known browser because it was available for free non-commercial use. However, as part of the Windows 95 Plus! package, Microsoft released Internet Explorer 1.0.

Just three months later, Internet Explorer 2.0 became available for free download. All Windows users, including commercial organizations, could use the browser for free, which was its key advantage over Netscape Navigator.

From that point on, every Netscape Navigator and Internet Explorer update was an attempt to outdo the competition. In 1996, Internet Explorer began seriously challenging Netscape's browser when it became the first to offer commercial support for Cascading Style Sheets (CSS).

The browser wars involved more than just the companies behind the browsers. Web designers at the time actively placed badges on their websites saying things like "Best viewed in Netscape" or "Best viewed in Internet Explorer." These badges usually linked to the corresponding browser download page and meant that the site had only been tested in one of them. In response, supporters of the open web launched the "Viewable with Any Browser" campaign.

In the end, Microsoft won the battle, securing over 90% of the global market. This was primarily due to the widespread adoption of Windows, which came preinstalled with Internet Explorer as the default browser.

Back in 1998, when defeat became inevitable, Netscape released the source code of its browser. This decision would later play a role in future browser wars. In 2003, AOL, which owned Netscape by that time, finally disbanded the development team.

Meanwhile, Microsoft faced a major lawsuit from the U.S. Department of Justice for violating antitrust laws. The court ruled that the company held a monopoly, requiring it to allow computer manufacturers and users to remove Internet Explorer access icons and install different browsers without altering the Windows interface.

That same year: the first JSON message

The first message in JSON format was sent in April 2001 from a computer in a garage in the San Francisco Bay Area.

Douglas Crockford and Chip Morningstar, co-founders of the State Software technology consulting company, were already trying to build AJAX applications even before the term AJAX was first coined.

The message looked like this:

html<html><head><script>
    document.domain = 'fudco.com';
    parent.session.receive(
        { to: "session", do: "test",
          text: "Hello world" }
    )
</script></head></html>

Only a small part of it resembles the JSON we know today. The message itself is an HTML document containing JavaScript code.

The format was originally supposed to be called JavaScript Markup Language (JSML), but that acronym was already taken by Java Speech Markup Language, so it was renamed to the JavaScript Object Notation we know today.

The authors realized they had developed a versatile format, but customers were reluctant to use an unproven technology without specifications.

This prompted Crockford to purchase the JSON.org domain in 2002, where he published the JSON grammar and a parser implementation.

2004. Google invents AJAX

On April 1, 2004, Google launched Gmail, marking the first large-scale showcase of AJAX. The service loaded emails, updated the interface, and displayed search suggestions without reloading the page, which was a true breakthrough at the time. Paul Buchheit, project creator and one of Google's first employees, used XMLHttpRequest to make the browser experience feel like a desktop application.

Interestingly, the term AJAX appeared a little later. In February 2005, Jesse James Garrett introduced it in his article "Ajax: A New Approach to Web Applications."

Asynchronous JavaScript and XML (AJAX) is an approach to web application development that enables websites to exchange data with a server in the background without fully reloading the page.

AJAX marked the beginning of a new era in web applications and frameworks. It also kicked off Web 2.0, which transformed internet users from passive readers into active content creators.

2006. jQuery

John Resig created jQuery at BarCamp NYC in January 2006. Its key sources of inspiration included Dean Edwards' CSSQuery library and other community projects from that time.

The library was designed to streamline common tasks like DOM traversal, event handling, and AJAX.

jQuery fixed many issues caused by browser incompatibilities, attracting developers with its well-documented and concise API.

As of August 2022, 77% of the 10 million most popular websites used jQuery. On average, jQuery was used three to four times more often than any other JavaScript library, according to web analytics.

2007. Apple reinvents mobile web

When the first iPhones hit the market in 2007, they didn't support Flash, which was the top technology for interactive web content at the time. Flash powered videos, animations, and browser games. Instead of actual content, users saw empty rectangles on websites opened in mobile Safari.

Critics pointed out the obvious contradiction that without Flash, Apple's promotion of Safari as a "full-featured browser" was an exaggeration. Seizing the opportunity, Android added Flash support in version 2.2, presenting it as a key advantage over the iPhone.

In April 2010, Steve Jobs published an open letter titled "Thoughts on Flash." He explained why Flash would never appear on Apple devices: a proprietary technology developed in the mouse-driven era was incompatible with touchscreen interfaces. Flash used too much power and wasn't compatible with hardware acceleration on mobile chips. According to Jobs, the future belonged to open-source standards: HTML5, CSS, and JavaScript.

The market ruled in Apple's favor. The iPhone and iPad quickly gained market share, and web developers had to rewrite websites without Flash while also solving mobile adaptation issues.

In November 2011, Adobe ceased development of Flash for mobile devices and announced the end of the desktop version in 2017. Flash officially ceased to exist on December 31, 2020.

JavaScript was the biggest beneficiary of this story. Open-source standards filled the void left by Flash, with JS becoming their main driving force.

2008. Google Chrome

For six years, Google CEO Eric Schmidt opposed the development of the company's own web browser. He had several reasons for doing so, but the main one was that he didn't want to drag the company into another browser war.

However, the company's co-founders, Sergey Brin and Larry Page, hired several Mozilla Firefox developers and created a demo version of Chrome. Schmidt later admitted, "It was so good that it essentially forced me to change my mind."

On September 2, 2008, Google released the first beta version of Chrome. Thanks to its new V8 JavaScript engine, the browser was built around performance from the start.

Google's engine was revolutionary. Open source from day one, it influenced the development of other tools, most notably Node.js.

The release of Google Chrome marked an important milestone in the second browser war.

That same year: ECMAScript 4 gets canceled

Development of the new language version began in 2000 and continued through 2008; the creators envisioned it as a complete overhaul of JavaScript. However, it caused a real crisis within TC39.

The committee split into two groups: supporters, including Adobe, Mozilla, Opera, and Google, and opponents, including Microsoft and Yahoo. The first group wanted large-scale changes, while the second considered ES4 too complex and incompatible with existing code.

The situation got so bad that Microsoft effectively sabotaged the process by blocking the adoption of proposed changes.

In the end, ECMAScript 4 was canceled. Instead, a more conservative ECMAScript 5 was released later, while some of the biggest changes returned with the release of ES6. Adobe developers adopted many of those ideas, which became part of ActionScript 3.

Following this, TC39 introduced a staged process where each feature follows its own path from proposal to inclusion in the standard. This approach paved the way for the annual release of new ECMAScript versions in the future.

2009. Node.js

The first version of an open-source, cross-platform JavaScript runtime environment outside of a browser was released in May 2009, approximately 13 years after Netscape introduced the LiveWire Pro Web server environment.

Ryan Dahl, the creator of Node.js, criticized the Apache HTTP Server for its limited capacity to handle large numbers of simultaneous connections and the sequential programming approach dominant in the industry.

Node.js overcame these challenges by combining Google's V8 engine, an event loop, and a low-level I/O API.

Node.js was first presented on November 8, 2009, at JSConf. In early 2010, npm, a package manager for the Node.js environment that allows developers to publish and share packages, was introduced.

The same year: ECMAScript 5

Released in 2009, ECMAScript 5 was the first major update to the language since ES3. It introduced many features that have become essential to JavaScript.

This version added the use strict directive. It helped identify errors that engines previously ignored. For example, creating a variable without first declaring it started throwing a ReferenceError.

It also added many features for working with strings, arrays, objects, JSON, and dates.

It's difficult to imagine modern code without features like Array.forEach, JSON.stringify, and Date.now, all of which appeared in this version of the language.

That same year: Oracle acquires Sun Microsystems

In April 2009, Oracle announced its acquisition of Sun Microsystems, with the deal closing in January 2010. Along with Sun, Oracle also acquired the JavaScript trademark.

The acquisition of the trademark by the corporation resulted in several unusual situations. For example, the Rust for JavaScript Developers community received a letter demanding that they stop using the word "JavaScript" in their name. When renewing the trademark in 2019, Oracle submitted a screenshot of the Node.js website to the USPTO as proof of use, as if claiming ownership rights over any JavaScript projects.

In 2022, this situation led Ryan Dahl, the creator of Node.js and Deno, to publicly ask Oracle to give up the trademark. In 2024, an open letter was released and signed by over 27,000 developers, including Brendan Eich, the creator of JavaScript.

The Deno team filed a petition with the USPTO to cancel the trademark in November of the same year. The case is still ongoing.

Read our article on the history of Java to learn more about how Sun Microsystems was acquired by Oracle.

2012. TypeScript

TypeScript, a language that added static typing to JavaScript, was released in October 2012. The project aimed to streamline the development and maintenance of large-scale JavaScript applications. Anders Hejlsberg, the creator of Turbo Pascal and C#, started developing it in 2010 at Microsoft.

Over the years, TypeScript has influenced the entire ecosystem.

Many TypeScript features appeared before they became part of the ECMAScript specification, including optional chaining (?.), nullish coalescing (??), and others.

Also, strong typing, once considered unnecessary in the JavaScript world, has become the norm. Nowadays, many libraries, both large and small, ship with .d.ts declaration files.

2013. React

React is a library for building UIs. It was first introduced at the JSConf US conference in May 2013.

Development of React began at Facebook in 2010: Jordan Walke created an internal prototype called FaxJS for the news feed. By 2011, React was already in use within the company. The community response was skeptical, with people asking, "How can you mix HTML and JavaScript?"

However, React changed the way developers build interfaces. The component-based model, Virtual DOM, and the one-way data flow have become the new industry standard.

Vue.js, released in 2014, took direct inspiration from React's ideas. Starting with version 2, Angular also switched to a component-based architecture. These approaches have now become the standard.

React Native was released in 2015, enabling developers to build mobile applications using React and paving the way for JavaScript in mobile development.

The Hooks API, introduced in React in 2019, replaced class components and popularized a functional approach to writing code across the JavaScript ecosystem.

The same year: Electron

The framework started as an internal GitHub tool for the Atom text editor, which entered public beta in April 2014. It combines Node.js and Chromium, enabling developers to reuse web code with minimal changes while running it in a controlled browser environment that provides native application privileges.

The technology's potential was quickly recognized, prompting the renaming of Atom Shell to Electron in April 2015. Slack was among the first major adopters, transforming its web client into a full desktop application. Many other products soon followed.

Electron revolutionized desktop application development by making it accessible to the web development community. In the past, building cross-platform applications required extensive knowledge of native technologies. Electron allowed developers to create them using only HTML, CSS, and JavaScript.

2014. Webpack

In 2012, Webpack was released as an open-source JavaScript module bundler. It takes dependencies as input and builds a dependency graph, enabling developers to take a modular approach to web application development. This allowed them to import almost anything to client-side code and, over time, became the foundation of the build process for React, Angular, Vue, and many other frameworks.

The foundation laid by Webpack later gave rise to modern build tools, including Rollup, Vite, and ESBuild.

2015. ECMAScript 6

The new language standard, released in 2015, was the largest update in JavaScript's history. In many ways, JavaScript split into two eras: before and after ES6.

The new version introduced let and const as replacements for var, bringing block scope and eliminating many classic hoisting-related bugs. It also brought arrow functions, which made code more concise and solved common issues with the this context. ES6 also added classes, modules, destructuring, and the spread and rest operators.

ES6 introduced Promise as JavaScript's native solution to the callback hell problem. ES8 later built on that foundation with async/await.

Many practices that are now considered standard in modern JavaScript originated with ES6.

That same year: the end of the second browser war

The second browser war lasted much longer than the first one, and it was on a completely different scale. While the first one was a showdown between Netscape and Microsoft, the second one was a battle of everyone against everyone else.

By 2015, Internet Explorer still held around 80% of the market. Microsoft had grown complacent, causing the browser to stop evolving. Users noticed the stagnation and started switching to other options.

Mozilla Firefox and Opera were the first to capitalize on the situation. Firefox launched in 2004 and immediately offered features Internet Explorer lacked: tabbed browsing, extensions, and better performance. The "ghost" of Netscape had returned for a rematch.

Microsoft responded too late. After five years of stagnation, Internet Explorer 7 was released in October 2006. Microsoft even allowed users with pirated Windows copies to install the new version, but that didn't stop them from leaving. Internet Explorer continued to lose market share quickly.

In 2008, Google Chrome entered the race and permanently shifted the balance of power. Its fast V8 engine, minimalist interface, and aggressive promotion through Google's services all contributed to its success. By the early 2010s, Chrome had overtaken every competitor.

IE lingered on for a few more years until Microsoft released Edge in 2015. Internet Explorer was officially discontinued in 2022.

Chrome has become the web's most popular browser.

2016. Visual Studio Code

Visual Studio Code, a code editor created by Microsoft, was first introduced on April 29, 2015, at the Build conference.

Microsoft developed it during a period of major change in the web development field, when many developers were switching to lightweight editors like Sublime Text and Atom. At the time, Microsoft was still closely associated with the heavyweight Visual Studio IDE. VS Code was built on Electron and has been open source and cross-platform since day one.

The community initially reacted with caution. Many doubted Microsoft's ability to build a tool that would appeal to everyone.

However, VS Code redefined what a code editor could be. Its powerful Extension API and built-in debugger combined with a lightweight user experience proved to be exactly what the market had been missing.

Language Server Protocol was one of the important byproducts. The VS Code team proposed the standard for language integration, which quickly gained adoption across the industry in editors such as Vim, Emacs, and Eclipse. Stack Overflow's developer survey ranked VS Code as the most popular development tool in 2018, and it has held that position ever since.

VS Code was especially important for the JavaScript ecosystem because it shipped with built-in support for JavaScript and TypeScript from the beginning.

By the way, we're developing a Visual Studio Code extension that makes it possible to work with PVS-Studio directly from within the editor. You can learn more about it in the documentation.

2017. WebAssembly

WebAssembly is a binary instruction format for a stack-based virtual machine that became a W3C web standard in 2019. It emerged after years of struggling against JavaScript's performance limits.

Back in 2013, Mozilla introduced asm.js, a strict subset of JavaScript with explicit type annotations that browsers could compile ahead of time. A live demonstration of Unreal Engine 4 running directly in Firefox proved the concept was viable and made a strong impression. However, asm.js was cumbersome, and only one browser supported it.

In 2015, Mozilla, Google, Microsoft, and Apple came together to develop a solution. They all faced the same challenge: JavaScript engines had reached an architectural limit that compiler optimizations alone couldn't overcome.

The MVP was released in early 2017 and appeared in all four major browsers almost simultaneously, which was a level of coordinated rollout the web had never seen before. For compute-intensive workloads, WebAssembly achieved 60–80% of native performance.

Its arrival opened up new possibilities that were previously impossible in web development. For example, Figma rebuilt its rendering engine using C++ and converted it to Wasm, enabling its browser-based editor to perform like a native application. Adobe Photoshop also made its way to the browser, while Unity and Unreal Engine got official Wasm export support.

Although WebAssembly proved invaluable for workloads where JavaScript struggled, it never fully replaced JavaScript—that was never the goal. Instead, JavaScript became the glue that connects Wasm modules to the DOM and browser APIs.

2018. Deno

In 2018, Ryan Dahl, the creator of Node.js, gave a talk at JSConf EU in Berlin titled "10 Things I Regret About Node.js." He outlined what he considered to be the biggest design flaws of Node.js, including its module system, unrestricted access to the network and file system, and so on.

He concluded the talk by announcing Deno (an anagram of Node—Ed.), a new JavaScript runtime that addresses those issues.

For example, instead of granting unrestricted access to the file system and network, Deno introduced permission flags such as --allow-write and --allow-net. Rather than relying on an ever-growing node_modules directory and package.json, it adopted URL-based imports similar to the way external JavaScript files are included in an HTML page.

The first stable version of Deno was released in 2020. In 2021, the project joined TC39. Although Deno differs from Node.js in many ways, its developers remain committed to the JavaScript standard.

Deno 2.0, released in 2024, maintained the original's simplicity while adding compatibility with Node.js and npm.

2020. Vite

In 2020, Evan You, the creator of Vue.js, made a surprisingly obvious point that had been overlooked by everyone: modern browsers already support native ES modules. This meant developers no longer had to bundle code during development. The browser could resolve the required modules on its own.

This idea led to the creation of Vite (French for "fast" — Ed.). Unlike traditional tools, Vite's development server didn't waste time bundling the entire project at startup. Instead, it sent source files directly to the browser like ES modules do, while using esbuild, a Go-based bundler, to pre-bundle dependencies from node_modules. As a result, the time required to initiate these large projects was reduced to mere seconds. When a single file changed, the browser no longer had to reload the entire project; it only needed to reload the modified module.

The first release focused exclusively on Vue, but in February 2021 Vite 2.0 arrived as a completely redesigned, framework-agnostic tool.

Vite played a major role in the decline of Create React App, the longstanding standard for building React projects.

The same ecosystem also gave rise to Vitest, a test runner that uses the same configuration as the build system, allowing developers to avoid duplicating settings for Jest. Vite redefined expectations for development speed in the JavaScript ecosystem, pushing competing tools to match its performance.

By the mid-2020s, Vite had become one of the world's most downloaded npm packages. In March 2026, Vite 8 was released with Rolldown as its sole bundler, replacing the previous esbuild + Rollup combination. Rolldown, written in Rust, enabled application builds that were dozens of times faster.

2022. React on the server

In December 2020, the React team published an RFC titled "Zero-Bundle-Size React Server Components." The idea was simple: what if some components never reached the browser at all? They would run on the server, issue the final output, and then disappear. No client-side re-rendering. No JavaScript added to the bundle.

The proposal addressed a very real problem: large dependencies ended up in users' browsers simply because components imported them. Also, it required a lot of requests: we first send JavaScript, which then fetches the necessary data.

For two years, React Server Components remained an experimental feature. They required a dedicated streaming server and worked only within a supporting framework rather than in React itself. Wider adoption began in October 2022 when the beta version of the App Router was introduced with Next.js 13. In May 2023, version 13.4 was declared stable. Server Actions came alongside it. These are functions marked with the use server directive that are called from the client but executed on the server.

From that point on, a single React project contained two distinct worlds, each with a different execution model. These worlds were separated by the use client and use server directives.

The impact extended far beyond React. Solid.js, Qwik, and Svelte all embraced the idea of sending less JavaScript to the client. Qwik built its entire resumability model around this concept. Instead of rerunning all the necessary JavaScript to rebuild a page, the browser resumes execution from where the server left off.

React 19, released in December 2024, officially added Server Actions to the public API. However, most developers still have to choose between the traditional approach and this newer model.

2026. PVS-Studio analyzer for JavaScript and TypeScript

On April 6, 2026, PVS-Studio launched an Early Access Program (EAP) for its new analyzers. For many years, PVS-Studio has helped developers catch bugs and vulnerabilities in C, C++, C#, and Java projects. Now it's JavaScript's and TypeScript's turn.

The initial release included 20 diagnostic rules, typo and logic error detection, a CLI version, and a plugin for WebStorm. TypeScript support and a VS Code extension followed in May.

The EAP also introduced a new analyzer for Go.

The new analyzers are scheduled for full release in August 2026, alongside PVS-Studio 8.00.

Conclusion

This is where our journey through the history of JavaScript comes to an end. It has been an eventful one, as JavaScript's story is deeply intertwined with the evolution of the web itself.

This article reflects the author's perspective on the history of JavaScript and may not include every milestone you consider significant. If you think something important is missing, please add it in the comments! :)

If you're interested in the history of other programming languages, check out our series of articles on the topic:

See ya soon!