DEV Community: Unicorn Developer

Pitfalls of bit fields in C++

Unicorn Developer — Fri, 30 Oct 2026 13:26:49 +0000

C++ is a language that lets developers do absolutely anything, and then it just silently watches as they blow everything up. We're used to thinking in terms of bytes, but what if the standard type system seems too wasteful? When your inner perfectionist demands compactness, bit fields are the best solution. Why use an entire eight-bit container for a simple yes-or-no flag when you can carve out exactly one bit with surgical precision? Add a colon, and suddenly you're the master of memory. However, when it comes to saving memory, order and predictability end. A programmer is left to deal with the subtleties of standards and the behavior of specific platforms. Let's take a look under the hood of C++ and see how bit fields actually work.

Introduction

How did I end up here, and why did I even decide to cover this topic?

For quite some time, I've been working on supporting the MISRA C++ 2023 rules. Yes, PVS-Studio analyzer learns how to check whether a codebase complies with this standard. My task was to implement support for a rule that regulates the co-use of enumerations and bit fields. It all looked simple in my head: all I had to do was check whether the enum values with a fixed fundamental data type fit within the specified bit field width.

Have you ever started a task that seemed like a fun little adventure that would take just a couple of hours, only to find yourself stuck in a bottomless pit of troubleshooting for an entire week? That's exactly what happened to me. I got bogged down in trying to implement support for this rule.

As I tried to untangle the mess, I realized one thing: bit fields in C++ are an underrated topic that every C++ developer should know about.

The basics: what are bit fields?

In C++, a bit field is a data-packing mechanism that allows you to allocate memory within a structure or class bit by bit instead of byte by byte. Unlike ordinary types, which always occupy at least one byte, bit fields enable you to allocate exactly the number of bits you want to a particular variable. This makes them invaluable when memory is strictly limited or when you need to store a set of flags as compactly as possible.

Let's take a look at the syntax for declaring bit fields. It may differ slightly depending on your technical requirements, but the fundamental structure is as follows:

type-specifier declarator : constant-expression ;

Here, constant-expression specifies how many bits to allocate to a particular field.

The syntax for bit fields is quite interesting. We use a colon to give the compiler a direct instruction to override the usual memory allocation rules. In standard C++ code, the smallest addressable unit is a byte, which contains CHAR_BIT bits. The implementation defines the CHAR_BIT macro, but its most common value is eight. The colon separates the variable's logical name from its actual size. This forces the compiler to divide memory into small chunks of a specific size.

This approach saves memory. How? It eliminates empty and redundant bits. When you declare standard variables, the processor rounds their size up to whole bytes due to architectural constraints. Bit fields work around this limitation by packing multiple fields into a shared storage unit.

To understand how bit fields save space, we'll compare two ways of storing the same data. Let's say we need to record three system parameters:

activity status (on/off): 1 bit is enough (values 0 or 1);
mode (4 modes): 2 bits are enough (combinations 00, 01, 10, and 11);
error code (from 0 to 7): 3 bits are enough (combinations from 000 to 111).

All the essential information about the object state takes up exactly six bits.

Option 1. Standard structure

If we create a standard structure in C++, the compiler allocates one byte of memory for each type, since this is the minimum addressable size:

struct StandardStruct 
{
  bool is_active;   
  char mode;        
  char error_code; 
};

The full code
The example:

#include <iostream>

struct StandardStruct 
{
  bool is_active;   
  char mode;        
  char error_code; 
}; 

int main()
{
  StandardStruct stStruct;
  std::cout << "Sizeof stStruct: " << sizeof(stStruct)
            << "byte(s)" << std::endl;
}

Program output

Sizeof stStruct: 3 byte(s)

The program uses 24 memory bits. 24 memory cells were allocated for our six units of information; the remaining 18 cells simply remain empty because the processor architecture can't directly handle units smaller than one byte.

Option 2. Structure using bit fields

Now let's add the colon syntax. The compiler starts with a fundamental data type, or container, such as unsigned char, which is one byte (eight bits) in size. It then begins packing fields tightly inside the container:

struct BitFieldStruct
{
  unsigned char is_active  : 1; 
  unsigned char mode       : 2; 
  unsigned char error_code : 3; 
};

The full code
The example:

#include <iostream>

struct BitFieldStruct
{
  unsigned char is_active  : 1; 
  unsigned char mode       : 2; 
  unsigned char error_code : 3; 
};

int main()
{
  BitFieldStruct stStruct;
  std::cout << "Sizeof stStruct: " << sizeof(stStruct)
            << " byte(s)" << std::endl;
}

Program output

Sizeof stStruct: 1 byte(s)

As a result of this mechanism, the entire structure is compressed to one byte. In memory, it appears as a single eight-bit array divided into sectors:

The compiler handles everything: when reading from or writing to the mode variable, it automatically generates hidden bit shifts and masks to isolate the required two bits from the rest of the data. This high-density packaging significantly reduces RAM usage in large arrays and embedded systems (microcontrollers).

How bit fields work and their limitations

We've covered the basic principles and syntax of bit fields. Now let's take a closer look at how they work and explore the rules imposed by the language.

Bit fields can exist only inside structures or classes. Developers can't declare a bit field as a standalone variable inside a function. It's also impossible to apply the const or volatile qualifiers directly to an individual bit field. Instead, you can apply them indirectly by declaring an object of that structure or class with the relevant qualifier.

Data types for bit fields

The next thing to discuss is which data types you can use with bit fields. The C++ standard allows this mechanism only for integral types and enumerations. Trying to limit the bit width of floating-point types (float, double) or complex objects such as std::string is technically impossible and will result in a compilation error.

Bit fields support the following types:

1. Integral types (char, wchar_t, char8_t, char16_t, char32_t, bool, short, int, long, and long long).

These are the standard options for creating masks and flags. Before C++14, explicitly specifying the signed or unsigned modifier for an int bit field was critical. Otherwise, the compiler determined how to interpret the signed bit. For example, a one-bit int field without an explicit unsigned modifier could take 0 and -1 instead of the expected 0 and 1. For a bool field, allocating exactly one bit is enough.

2. _Enumerations (enum and enum class)._

Bit fields work well for storing enum types with a small set of possible values. If an enum has four possible states, allocating two bits is enough.

3. _std::byte (_C++20).

Starting with C++20, std::byte officially joined the list of permitted types. If a structure handles raw data at the hardware level, using std::byte clearly communicates the developer's intent and prevents accidental arithmetic errors.

Rules for working with bit fields

The third important topic to cover is the rules governing bit fields. In C++, four key restrictions apply. Developers cannot:

declare an array of bit fields;
take the address of a bit field;
create a pointer to a bit field;
create a reference to a bit field.

Let's look at some examples to understand why bit fields follow these rules and what happens when you try to get around them. We'll start with a simple structure:

struct HardwareFlags
{
  unsigned int mode   : 3;
  unsigned int status : 1;
};

No taking addresses or creating pointers

The rule against taking addresses or creating pointers stems from a fundamental aspect of computer architecture: a bit field has no physical memory address. Modern processor architectures use the byte as the smallest addressable unit of memory (CHAR_BIT bits). A processor simply has no way to address, say, the third bit within a byte.

For this reason, we can't use the address-of operator & on a bit field:

HardwareFlags flags;
auto address = &flags.mode;
int* ptr = &flags.mode;     // doesn't compile

Since individual bit segments don't have unique addresses in a memory cell, it's physically impossible to obtain a direct pointer to such a variable.

No address, no references

There's another restriction that comes from the inability to take a bit field's address: you can't bind a standard reference & to a bit field. In C++, references rely on pointers and memory addressing. Without an address, there's simply nothing for a reference to bind to:

HardwareFlags flags;
void checkMode(const unsigned int& m);

unsigned int& ref = flags.mode;        // doesn't compile
checkMode(flags.mode);                 // doesn't compile

Arrays: why pointer arithmetic falls short

I'm afraid I have some bad news: you can't create an array of bit fields either. The reason lies in pointer arithmetic. When you create an array, the compiler guarantees that its elements occupy consecutive memory locations. When you access the i-th element using arr[i], the compiler calculates its address relative to the start of the array via pointer arithmetic.

struct BrokenStruct
{
  unsigned int items[5] : 2; // doesn't compile
};

The anatomy of alignment

Although bit fields aim to save memory, C++ doesn't specify their exact layout within a structure. Compiler developers have considerable freedom in how they pack bits, so a structure's actual size depends on the target platform. This flexibility is impressive, but to understand why it exists, let's take a look at what the standard says:

Allocation of bit-fields within a class object is implementation-defined. Alignment of bit-fields is implementation-defined. Bit-fields are packed into some addressable allocation unit.

[Note 1: Bit-fields straddle allocation units on some machines and not on others. Bit-fields are assigned right-to-left on some machines, left-to-right on others. — end note]

In reality, this means that the layout rules come not from the language, but from the Application Binary Interface (ABI) defined for a particular OS. For example, many Unix-like systems use the Itanium ABI, but it also leaves some aspects of bit ordering unspecified. The packing rules can vary depending on the OS and architecture. For example, MSVC on Windows and GCC on Linux may compile the same structure differently.

In this section, we'll focus specifically on how bit fields work. I'll touch on alignment briefly, as I've already covered it in a series of articles: the first part introduces the basic principles, while the second and third explore how inheritance and virtual functions affect alignment.

How compilers divide memory into allocation units

The phrase "Bit fields are packed into some addressable allocation unit" describes the concept of an allocation unit. According to the C++ standard, an allocation unit is an addressable block of hardware memory, such as a byte or machine word, into which bit-fields are packed consecutively. The exact behavior of these units is implementation-defined and depends largely on the platform's ABI.

A compiler never allocates memory for individual bits out of thin air. Instead, it starts with the fundamental data type you specify when declaring a field and uses it to determine the size of the physical container. For example, if you use unsigned char, the allocation unit is one byte (8 bits). If you choose unsigned int, it occupies four bytes (32 bits). The compiler takes this entire physical container and starts slicing it into the specified logical segments, one bit at a time, until no space remains. Once the container runs out of room, the compiler allocates a new unit for the next fields.

Let's look at how a compiler packs data:

The packing algorithm

The compiler receives a list of bit fields declared in a structure.
It allocates the first container (memory allocation unit) based on the size of the fundamental data type.
The first bit field occupies the beginning of the newly allocated container.
The compiler calculates how many free bits remain in the current container.
It takes the next bit field from the list for analysis.
It compares the field's width in bits with the number of free bits remaining.
If the field fully fits in the remaining space, the compiler places it in the current container, directly next to the previous one.
After successfully placing the field, the compiler updates the free-bit counter and moves on to the next field.
If the field's width exceeds the available space, the compiler must resolve a standard ambiguity.
The compiler consults the ABI rules for the target architecture. On x86 and ARM, the compiler moves the entire field to a new container to preserve CPU performance. On other architectures, such as some RISC processors, it may split the field into two parts to maximize memory saving, filling the remaining space in the current container.
The compiler closes the current container, leaving any unused bits empty.
It opens a new, empty container (allocation unit).
The field that didn't fit occupies the beginning of the new container.
The compiler then recalculates the number of free bits in the new container and repeats these checks for the remaining fields.
The process is complete once the compiler has assigned all bit fields in the list to their respective containers.

Note. The direction in which the compiler fills a container depends on the ABI rules for the target architecture. The order can be from least to most significant bit or vice versa.

sizeof bloat: good vs. bad alignment

Why are we even going into such detail about the compiler's step-by-step algorithm? Bit fields can become a ticking time bomb if one doesn't understand these inner workings. You write code expecting to save memory, but end up with a structure that's several times larger than normal. Declaring bit fields haphazardly can trigger sizeof bloat. The compiler loses its capability to pack data tightly and starts inserting unused bytes.

Two classic developer mistakes usually lead to such hidden memory leaks:

Creating giant fields whose widths exceed the physical capacity of the current memory container.
Mixing data types indiscriminately, so adjacent fields keep switching between fundamental data types (for example, char, then int, and then char again). This is a critical issue on Windows (Microsoft ABI), where the compiler starts a new allocation unit whenever the type changes, leaving unused padding behind. This limitation doesn't affect GCC and Clang on Linux and macOS: they ignore changes in base types and continuously pack fields, minimizing alignment padding.

To see just how much of a difference this makes, let's compare two scenarios: one that shows how not to do it, and one that shows how to do it right.

Example N1. Inefficient layout (poor alignment)

Imagine a structure where we've tried to save memory by mixing different types. For this example, let's use MSVC on Windows:

struct BadPacking
{
  unsigned char a : 4;
  unsigned int b  : 3;
  unsigned char c : 4;
};

The structure fields will be arranged as follows:

The constant switching between types (char > int > char) completely disrupts continuous packing. MSVC treats each type change as a command to close the current allocation unit. It stops filling the byte after a, leaves the remaining bits as padding, and aligns the address for the next block. It then opens a 4-byte container for the int b field, which takes three bits, and immediately closes it to open a container for the char type. As a result, large gaps of unused memory remain. The compiler also has to follow alignment rules, so it performs final alignment on the entire structure. Then, sizeof(BadPacking) returns 12 bytes. Clang and GCC, on the other hand, can handle this structure efficiently: they know how to pack these fields as tightly as possible.

Example N2. Optimized layout (good alignment)

To fix this, simply follow the golden rule: convert all fields to a single base type and group them by meaning.

struct GoodPacking {
    unsigned int b : 3; 
    unsigned int a : 4;  
    unsigned int c : 4;  
};

Let's take a look at how the elements are arranged in the structure now:

The compiler now works with uniform and predictable four-byte blocks. The b field occupies almost the entire first block, while the a and c fields require only eight bits combined, fitting perfectly into the second int block. As a result, sizeof(GoodPacking) returns just eight bytes (exactly two int containers). The data is packed as tightly as possible so the processor can access it without any unnecessary overhead. This gives us a compact structure.

Hardware padding: reserving space for unused bits

When writing drivers, implementing network protocols, or working with processor registers, you may encounter hardware controllers with gaps in their bit layout. For example, a chip manufacturer may reserve certain bits in a hardware byte for future use, meaning you can't write or read data to or from them.

To precisely mirror the register's physical layout in code, you can use unnamed bit fields with non-zero widths as placeholders or padding:

struct TestController
{
  unsigned char transmit_ready : 1; 
  unsigned char                : 3; 
  unsigned char receive_ready  : 1;
  unsigned char                : 3; 
};

However, they still occupy their designated space in memory when the compiler generates the structure. This enables you to map a C++ structure to the microcontroller's physical memory layout with bit-level precision, without shifting any of the meaningful flags.

Forcing a packing boundary: why use a zero-width bit field?

In some cases, such as when working with hardware interfaces, it's necessary to prevent the compiler from packing fields into the current allocation unit. For example, you may need to ensure that the next data block starts at a new byte or machine word. To do this, you can use an unnamed zero-width bit field:

struct Test
{
  unsigned char command : 4; 
  unsigned char         : 0; 
  unsigned char data    : 4; 
};

A zero-width bit field acts as an artificial boundary. It tells the compiler that the current memory allocation unit is closed. The next field must start in a new allocation unit and can't use any remaining bits, even if plenty of space remains. One important rule to remember when working with these fields is that you can't give a zero-width bit field a name. It must always remain unnamed.

Under the hood: how compilers store bit fields

Now, it's time to take a look under the hood. The internal structure of bit fields in C++ is subject to implementation-defined behavior. The C++ standard abstracts away the physical details, providing only high-level rules and delegating the challenging tasks to the compiler and ABI. To understand how data actually occupies memory, we need to take a closer look at three fundamental factors: bit allocation order, compiler differences across architectures, and binary portability.

Bit allocation order

The first and most important factor that determines a structure's physical layout in memory is the order in which the compiler places bits inside an allocated container. Most developers are familiar with byte order, which determines how multibyte values are mapped to memory addresses. A similar concept exists at a lower level, though: the compiler decides which direction to fill individual bits within a particular byte or machine word. The C++ standard deliberately leaves this detail unspecified, so each compiler's implementation determines how it fills each container. In real world, compilers use one of two opposite approaches: packing from the least significant bit to the most significant bit (LSB-first, Little Endian) or from the most significant bit to the least significant bit (MSB-first, Big Endian).

In the LSB-first scheme, the compiler fills the allocated container from right to left. In other words, packing begins with the least significant bit, or bit 0. The first bit field declared in the structure occupies the rightmost bits, and each subsequent field sits directly next to it, extending leftward toward bits with greater binary significance. GCC, Clang, and MSVC all use this approach when compiling code for architectures such as x86, x86-64, and ARM.

The opposite strategy is MSB-first (Most Significant Bit-first). In this case, the compiler packs bits from left to right, starting with the highest available bit: for example, the seventh bit in a one-byte container. The first field in the structure occupies the most significant bits on the left side of the container, while subsequent fields follow in sequence toward the least significant bits. This is common in compilers for network processors.

Let's see how this works in real code. Take a look at the following structure:

struct HeaderFlags
{
  uint8_t version : 3; 
  uint8_t type    : 2; 
  uint8_t id      : 3; 
};

The full code

#include <cstdint>
#include <cstring>
#include <iostream>

struct HeaderFlags
{
  uint8_t version : 3; 
  uint8_t type    : 2; 
  uint8_t id      : 3; 
};

uint8_t result_byte = 0;

int main()
{
  HeaderFlags flags;
  flags.version = 1;
  flags.type = 2;
  flags.id = 4;

  std::memcpy(&result_byte, &flags, sizeof(HeaderFlags));

  return 0;
}

We created a HeaderFlags structure that occupies exactly one byte and assigned three values to its fields. To safely extract the packed byte without violating memory access rules, we used std::memcpy and copied the result into the result_byte global variable.

Now let's see how different compilers handle this code. To avoid wading through unnecessary assembly instructions, we'll enable the -O2 optimization level.

The GCC x86-64 output:

        .globl std::ios_base_library_init()
"main":
        mov     BYTE PTR "result_byte"[rip], -111 ; <=
        xor     eax, eax
        ret
"result_byte":
        .zero   1

The mov instruction contains the -111 negative value, which is how x86-64 assembly represents one-byte constants. Converting it to the familiar unsigned format gives us 256 - 111 = 145, which is 0x89 in hexadecimal or 0b1001'0001 in binary. The compiler has eliminated all the intermediate packing instructions and written the final result directly to memory. Since the target cell occupies four bytes, the 0x00000089 value appears in memory as the 89 00 00 00 byte sequence. The fact that the least significant byte 89 appears at the lowest memory address confirms the LSB-first (Little Endian) layout.

Switching the compiler to the Big-Endian MIPS architecture, such as mips-linux-gcc 16.1.0, reveals a completely different picture. The assembly output for this platform looks as follows:

        .globl std::ios_base_library_init()
main:
        lui     $2,%hi(result_byte)
        li      $3,52                 # 0x34
        sb      $3,%lo(result_byte)($2)
        jr      $31
        move    $2,$0

result_byte:
        .space  1

Here, the li $3, 52 instruction loads the precomputed constant 52, which is 0x34 in hexadecimal and 0b0011'0100 in binary. The compiler uses the MSB-first strategy, packing bits from left to right: the version field occupies the most significant bits 7–5, type occupies bits 4–3, and id lands in the least significant bits 2–0. We can illustrate the bit layout schematically as follows:

This example shows how changing the bit endianness can completely change the physical representation of data. Directly transferring raw bytes between systems that use different bit-packing schemes can corrupt the data structure. Understanding this mechanism leads us to the second key factor: the architectural differences between compilers and the role of the ABI.

Platform dependence: the anatomy of the MSVC vs. GCC/Clang conflict

We often think that fundamental data types in C++ behave deterministically on the same hardware architecture. However, bit fields have an important caveat: the compiler decides how to arrange them in memory. The in-memory layout of the same structure compiled for an x86-64 processor can differ significantly between Windows and Linux. The physical layout of bit fields follows the rules defined by the ABI. The ABI specifies how the operating system's platform expects the compiler to group, align, and divide data into individual fields.

Several ABI standards define different approaches to data packing. Here are some of the most widely used ones:

System V ABI (based on the Itanium C++ ABI) is used by default in GCC and Clang on Linux, macOS, and FreeBSD. Although developers originally designed this standard for Intel Itanium processors, it has become a common foundation for GCC and Clang across various architectures, including x86, x64, and ARM64.
RISC-V ABI is a specification for the RISC-V open-standard architecture. This standard isn't formally derived from the System V ABI, but it shares many similar data packing and alignment rules. The goal is to pack bit fields in memory as tightly as possible.
Microsoft x64 ABI is used by default in MSVC on Windows systems running on the x86-64 architecture.
Microsoft ARM64 ABI is the modern Windows standard for ARM64 processors. It's designed with x64 limitations in mind. Its structure alignment rules offer greater flexibility, and its calling convention enables programs to pass data directly through registers, reducing stack usage.

These documents differ in a single rule.

The rule. Compatibility between different data types

Developers can declare consecutive bit fields with different fundamental data types within the same structure. This kind of type mixing is one of the main causes of hidden memory bloat, as compilers use very different algorithms to handle boundaries between allocation units with different fundamental types.

Let's see what happens when these rules conflict. We'll run an experiment using Compiler Explorer and measure the structure's size with the sizeof operator. Let's write the following structure:

struct PackagingConflict
{
  uint8_t  mode : 4; 
  uint32_t type : 4; 
};

The full code

#include <iostream>
#include <cstdint>

struct PackagingConflict {
    uint8_t  mode : 4; 
    uint32_t type : 4; 
};

int main() {
    std::cout << "--- BITFIELD PACKING SIZES ---" << std::endl;
    std::cout << "1. PackagingConflict size: " << sizeof(PackagingConflict)
              << " byte(s)" << std::endl;    
    return 0;
}

Look at the outputs from Clang and MSVC:

The Clang program output

--- BITFIELD PACKING SIZES ---
1. PackagingConflict size: 4 byte(s)

The MSVC program output

--- BITFIELD PACKING SIZES ---
1. PackagingConflict size: 8 byte(s)

Here's a visual layout of the memory components:

Upon analyzing this structure, we can spot a clear difference: Clang packs it into four bytes, while MSVC inflates it to eight. Since the fields use different fundamental data types (uint8_t and uint32_t), both compilers initially keep them separate. They allocate one byte for the mode and add three bytes of padding so the type starts at a properly aligned four-byte boundary. Clang then applies an Itanium ABI optimization, trimming the unused part of the second allocation unit to save space. MSVC, on the other hand, strictly follows the Microsoft ABI rule that the structure's total size must be a multiple of its largest fundamental type (uint32_t, or four bytes). It preserves the full four-byte allocation unit for each block, doubling the structure's final size.

The real danger is when we move between platforms with different ABIs, the well-defined physical boundaries of data in memory simply disappear. Hidden padding and differences in how compilers handle unused space within allocation units can completely change the internal field layout. This makes bit fields unsuitable for direct byte-by-byte copying, file storage, or binary serialization. If a structure is saved using Clang's four-byte layout and then read using MSVC's eight-byte layout, the program reads from incorrect offsets, resulting in corrupted data.

Binary fragility and industry standards

Due to inconsistencies in alignment and bit ordering, structures containing bit fields offer virtually no binary portability. C++ compilers treat bit fields as a black box: you write concise code, but leave the actual memory layout to chance.

Using bit fields is virtually guaranteed to cause problems in three areas:

1. Network I/O. Sending a structure directly over a socket with a call like send(sock, &packet, sizeof(packet), 0) is a ticking time bomb. If the server runs Linux (Clang) and the client runs Windows (MSVC), ABI differences can shift bit positions, turning valid flags into a meaningless jumble.

2. File I/O (serialization). For example, writing bit fields directly to a file byte by byte with fwrite ties the data to a specific ABI. According to Section 6.7.2.1 of the ISO C standard, the order in which compilers lay out bit fields and padding is implementation-defined behavior. Writing such a structure to a file on Linux and then reading it on Windows can cause differences between the Microsoft and System V ABIs to result in the program reading corrupted data from incorrect offsets.

The C++ object model in C++23 partially addresses the issue of object lifetimes with the std::start_lifetime_as function. However, this function only validates the creation of an object from raw bytes in memory; it doesn't address differences in the physical layout of fields across platforms. Moreover, copying uninitialized structure padding when writing data to a file technically involves reading indeterminate values, which leads to undefined behavior.

3. Drivers and hardware (Hardware MMIO). A microcontroller's hardware defines the bit layout of its registers, and it never changes. In C, however, the order and alignment of bit fields, as well as the width of memory accesses, depend on the implementation. So, describing a hardware register with bit fields doesn't guarantee that each field will map to the intended bits. Switching compilers, compiler versions, or build flags can shift the fields, causing writes to affect the wrong register bits.

Developers avoid bit fields entirely for any task that requires a strictly defined data layout, such as network communication, file storage, or hardware registers. Instead, they use fixed-width integer types (uint8_t, uint16_t, and uint32_t) combined with explicit bit shifts (<<, >>) and bit masks (&, |).

Differences between compiler ABIs make it difficult to use standard bit fields without manual alignment for cross-platform data exchange. A program compiled on Linux using GCC or Clang produces a data structure that a Windows application built with MSVC can't read correctly because the Windows application expects alignment and padding bits in different locations.

Use cases: where bit fields actually make sense

In C++ development, bit fields serve specific engineering needs rather than abstract memory-saving goals. There are two main scenarios where this feature proves most useful.

1. Compact metadata for millions of objects. Developers often need to store metadata, such as status flags, type IDs, and reference counts, for huge numbers of small elements when designing game engines, custom memory allocators, or databases. Allocating a separate variable for each flag can waste enormous amounts of memory due to compiler-imposed alignment. Bit fields let you pack several independent properties into a single byte, minimizing memory usage.

2. Optimizing CPU cache usage (Cache Lines). Modern processors don't read data from RAM one item at a time. Instead, they fetch large blocks of data called cache lines, typically 64 bytes each. When a data structure becomes too large, each cache line contains fewer useful objects. This forces the processor to repeatedly wait for slow RAM access, resulting in a cache miss. Using bit fields to pack data tightly allows the CPU cache to hold several times more objects. An algorithm can run several times faster when it iterates over objects sequentially in large batches because it retrieves data from the CPU's ultra-fast cache.

Modern alternatives to bit fields

Due to portability issues, dependence on platforms, and restrictions on address taking, developers often need to look for alternatives to traditional bit fields. Modern C++ offers three main architectural alternatives, each designed to address a specific use case.

The classic approach: manual bit masks and shifts

If you need to have complete control over the physical position of each bit, the classic C-style approach is your best option. Rather than relying on the compiler to automatically pack bits, you select a fixed-width integer type and manually manipulate individual bits using bitwise operators (&, |, ~, ^, <<, and >>).

Take a look at the example:

class DeviceConfig
{
public:
  void set_mode(uint8_t mode)
  {
    data = (data & ~MODE_MASK) | ((mode << 1) & MODE_MASK);
  }

  uint8_t get_mode() const
  {
    return (data & MODE_MASK) >> 1;
  }

private:
  static constexpr uint8_t ENABLE_CLOCK_MASK = 0x01;
  static constexpr uint8_t MODE_MASK         = 0x0E;
  static constexpr uint8_t INTERRUPT_MASK    = 0xF0;

private:
  uint8_t data = 0;
};

Yes, this code is more complex, but its binary layout is now completely independent of the compiler and ABI. This makes it an ideal approach for implementing network protocols and writing device drivers. The only thing developers need to keep in mind is the processor's byte order, or endianness. Multi-byte values appear in reverse order on Big Endian architectures compared to Little Endian ones.

For maximum safety: the std::bitset container

The built-in std::bitset class is the best choice if code safety and convenient manipulation of Boolean flags matter more than saving memory in individual structures.

This container provides a fixed-size array of bits whose size is specified as a template parameter at compile time. It encapsulates all bitwise operations, providing developers with a high-level, type-safe interface.

Look at the following example:

#include <bitset>
#include <iostream>

enum Permission
{
  Read = 0,
  Write = 1,
  Execute = 2,
  Admin = 3,
  MaxPermissions 
};

void ManagePermissions()
{
  std::bitset<MaxPermissions> user_rights;
  user_rights.set(Permission::Read);    
  user_rights.set(Permission::Write);   
  user_rights.flip(Permission::Execute); 

  if (user_rights.test(Permission::Write))
  {
    std::cout << "The user can write files.\n";
  }

  std::cout << "Current rights mask: " << user_rights << "\n";
}

int main()
{
  ManagePermissions();
}

The main advantage of std::bitset is that it protects against human error. If you pass an invalid index to one of its member functions—std::bitset<N>::set, std::bitset<N>::reset, std::bitset<N>::flip, or std::bitset<N>::test—such as index 15 for a four-bit bitset, the function throws a std::out_of_range exception. With manual bit masks, the same mistake could lead to unpredictable reads from unrelated memory or corrupt adjacent data.

There's a caveat, though: std::bitset typically rounds its internal storage up to the processor's native word size, so it can't save memory at the individual-bit level.

For large numbers of flags: the std::vector specialization

Using a regular bool array to manage a huge, dynamically sized array of Boolean flags wastes a lot of memory because each element occupies an entire byte. To fix this issue, the standard library provides a specialized version of std::vector: std::vector<bool>.

This container works differently from ordinary vectors. The standard library optimizes it for memory efficiency by packing bool elements bit by bit into larger integer types (machine words). Usually, it can store 32 or 64 Boolean values in a single memory block.

The following is an example of using a large dynamic array:

#include <vector>

std::vector<bool> feature_flags(10000, false);

void process_features()
{
  feature_flags[42] = true; 
  if (feature_flags[42])
  {
    // code
  }
}

Despite its convenience, std::vector<bool> is one of the most controversial features of the C++ standard. Developers should exercise caution when using it. Because it packs bits so tightly, its elements aren't actual bool objects in memory. As a result, you can't take the address of an element directly (the bool *ptr = &feature_flags[0]; code won't compile) or pass an element by reference or pointer. The [] operator returns a special temporary proxy object that mimics reference behavior rather than a reference. This is the trade-off for compressing data in dynamically allocated memory.

Conclusion

Well, that's all I have for you today. What can I say? Bit fields in C++ perfectly embody the language's philosophy. They give you complete freedom to cut out exactly one bit, then leave you alone to navigate the hidden landmines buried in compilers and system ABIs. Now that you've looked under the hood and seen how this intricate memory optimization coexists with platform-dependent chaos, there's no room for illusions. Bit fields are a powerful tool for optimizing cache lines and working with hardware. However, they can also create hidden issues when you try to send a structure over the network. Now you know the rules of this low-level game. How you wield this power over memory in your own projects is up to you.

Get a free one-month trial

Game++. Part 2.2: Types of optimization

Unicorn Developer — Fri, 23 Oct 2026 12:18:36 +0000

This book offers insights into C++, including the algorithms and practices used in game development, and explores the language's strengths and weaknesses, its established workflows, and hands-on solutions, because C++ still dominates the game industry today thanks to its combination of high performance, flexibility, and deep low-level control.

Hotspots and bottlenecks

The key task in optimization is to find hotspots, which are code fragments with a high computational load, and bottlenecks, which are components that limit overall throughput, and these problems usually fall into three categories, namely abstractions, smoothness, and hardware limitations.

Abstractions, or more precisely premature abstractions, add unnecessary layers to the engine architecture and make the whole system more complex than it needs to be, and the usual suspects here are multiple inheritance, one-size-fits-all solutions to game development problems, and heavy use of design patterns in places where simple procedural code would do the job just fine.

The same category includes writing beautiful code instead of fast code, when performance-critical sections get buried under unnecessary layers of ceremony and checks, which is exactly what the KISS principle warns us about.

Most developers agree that smoothness matters more than peak performance, and the things that work against it are well known, because sporadic memory allocations on the main thread make the frame rate uneven, algorithms with unpredictable complexity make frame times inconsistent, and blocking resource loads cause stuttering. A stable 30 FPS beats a frame rate that jumps between 60 and 20, because players feel those jumps immediately, which is why a consistent frame rate is such an easy-to-understand and measurable indicator of quality.

Hardware limitations are best treated as creative constraints, because brute-forcing a platform's physical limits instead of applying smart optimizations only adds complexity without any real payoff. Raising the polygon count without a proper level-of-detail system will leave the player with low FPS, and the same goes for complex shaders that ignore fill-rate limits, memory-hungry data structures that don't account for the cache hierarchy, and so on.

A modern CPU-GPU architecture is a complex data-processing pipeline with many parallel execution units, and in this "digital hell" data moves through a hierarchy of caches, travels between the CPU and GPU over the bus, and gets synchronized across threads with memory barriers and atomic operations, so the system almost never does exactly what you wrote in the code.

You can get solid and stable performance by balancing the workload across all of these components, and even then you may not be able to push the CPU beyond 70 to 80%, but you can make much better use of the GPU, memory bandwidth, and caches. The real challenge is finding a delicate balance right at the edge of what's possible for every component at once, and if you get it wrong, resource contention follows, one component becomes the critical link, and the rest of the system suffers from pipeline stalls, context-switching overhead, and reduced throughput.

Hotspots

In software systems, hotspots are localized sections of code with unusually high resource consumption, whether that's CPU time, memory, or disk I/O, and they're characterized by a disproportionately high execution frequency, heavy CPU utilization, high memory pressure, or significant system call overhead.

In the context of code optimization, the Pareto principle, also known as the 80/20 rule, means that 20% of the source code accounts for 80% of a program's total execution time, which makes hunting down hotspots a highly effective strategy. Searching iteratively helps you find the code blocks that consume the most resources so you can target them and cool them down, but once one issue is fixed, the workload shifts and previously minor sections turn into new hotspots that need attention. This process goes on until the results are acceptable or the time allocated for the task runs out, and it's worth remembering that an engineer's time is a finite resource too, because the more time a developer spends polishing one part of the code, the less time they have for everything else.

Modern profilers provide detailed analysis down to the level of individual CPU instructions, which makes it possible to identify temporal hotspots, code with a high number of cache misses, heavy I/O operations, and resource-lock contention in multithreaded applications.

Bottlenecks

Imagine a dish being prepared in a café. The chef can't make the whole thing at once, so they hand the side dish off to an assistant while working on the main part themselves, and then the two parts come together and a waiter takes the finished plate to the customer. How long will the whole process take? Suppose the chef finishes first, but the assistant simply can't work any faster, and now the assistant is the bottleneck that slows down the entire system.

Games work exactly the same way, because there's always a "slow assistant" somewhere, whether it's the CPU, the GPU, memory, or something in the code that holds everything else back, and the developer's job is to find that weak link and bring its performance in line with the rest. Optimization almost always involves trade-offs, and in 99% of cases there's no silver bullet that will fix the problem right away.

The first and most common trade-off is between performance and memory, since sometimes it's more efficient to store extra data than to recalculate it from scratch. This is called memoization or caching, and the idea is that you calculate something once, store the result, and then simply pull it from memory whenever you need it, which costs more memory but gets you the result faster.

The second trade-off is between accuracy and speed. Sometimes you can cut corners and speed up a system by simplifying a data type or using a less precise algorithm, and shaders are a good example, because they provide both log and logp, where the former is more accurate but slower and the latter is faster but less precise. In the final image, players are unlikely to notice that a neighboring polygon has shifted by a quarter of a pixel, but the game may run noticeably faster, and the same principle applies to almost any data model, pathfinding system, or game AI. The key question is how much precision you're willing to give up, or, in more formal terms, how much you can shift resources from lower-priority computations to higher-priority ones.

The third classic trade-off is simplicity versus speed, and this one has more to do with people and the team than with hardware. A classic example is a young, talented developer who has just discovered design patterns and responds by building five levels of nested caching in an attempt to optimize the texture-loading system.

Sure, they'll get that system built, and it may even run faster thanks to intrusive pointers, custom allocator pools, and a lock-free hash table, but the result is predictable, because nobody, not even the author a month or two later, can understand, debug, or modify that code without risking breaking something. Other developers on the team start avoiding those files, they groan every time they have to touch the system, and code reviews keep getting comments like "What the hell is this? Can we just rewrite it in plain C++?"

An experienced developer knows that real performance gains don't come from showing off their knowledge of algorithms, but from understanding the trade-off between how maintainable the code is and how much the optimization actually pays off.

Yes, you can squeeze out another 5% of performance with custom memory pools, but that will take two weeks to implement and another month to debug all the weird edge cases, so it might be smarter to use a simple linear allocator and trade some memory for time.

Mature optimization means fixing the truly critical bottlenecks with clean, well-documented solutions that you can easily switch off with conditional compilation if something goes wrong. In the real world, shipping the game matters more than cool algorithms, and having code the team can maintain matters more than having code that looks impressive in a conference talk.

Myths and misconceptions

Software optimization is inherently endless, because there will always be something left to improve, but it's important to understand that past a certain point you start hitting diminishing returns, and every additional effort delivers a smaller and less noticeable performance gain.

On top of that, developers often spend time chasing dead ends that provide no real benefit (but make for great slides and conference talks) and only make the system harder to maintain. The key skill here is knowing when to stop and ask whether further improvements will actually add value or turn into a witch hunt.

One of the most common mistakes is making decisions based on assumptions. You can't just "guess" what's slowing the system down, because those guesses are usually wrong, and the only reliable approach is to measure and analyze, then analyze and measure again, until guesses and gut feelings turn into well-founded engineering decisions.

Optimization doesn't start after the code is written, and in fact 80% of performance problems can be eliminated at the architecture design stage, because proper decomposition, a clear object hierarchy, and well-thought-out dependency management help you avoid bottlenecks in the first place. Despite the overhead that comes with languages like C# and Java, a well-structured system often outperforms code written in pure C++ that ignores architectural constraints.

When it comes to optimization, it's important to focus on worst-case scenarios rather than average ones. Most developers test their games and applications on powerful workstations, which often gives them a distorted picture, and on weaker hardware the bottlenecks can be completely different, with memory bandwidth or CPU power becoming the limiting factor instead of the GPU.

To analyze performance properly, developers need to deliberately test on configurations with minimal or weak hardware specs, because those machines are much closer to what a good portion of your players actually experience. Players can tell the difference between 55 and 60 FPS, but they rarely complain about it, while a drop to 20 FPS feels like serious lag even if it only happens once in a while, and that's why consistent frame times often matter more than a high average frame rate.

Debug and release builds give fundamentally different results (Pic. 3.1). In debug mode, compiler optimizations are turned off and extra checks are turned on, which can slow the code down several times over, and not evenly. For valid performance profiling, work only with release builds and enable debug symbols or disable optimization for specific sections when you need to, because this lets you strike a balance between traceability and accurate measurements while still giving you a realistic picture of performance.

Picture 3. 1

That said, debug builds are useful in the early stages of testing, when they can reveal excessive CPU usage or inefficient algorithms before those problems become critical.

Finally, the key requirement for any benchmark is control over external variables, since poorly designed tests can create the illusion of optimization. For example, the first measurement might be taken in fullscreen mode while the second runs in windowed mode, at a different refresh rate, or at a different resolution, and the frame rate goes up because the environment changed rather than the code, which makes the whole comparison meaningless. To avoid mistakes like this, keep every environment parameter fixed and change only one thing between runs, namely the piece of code you're optimizing. The best practice is to automate your benchmarks, which removes human error and gives you reproducible results.

Many people think optimization time should be added to sprints once the game is nearly finished, or, even worse, only when performance problems show up. But ignoring optimization in the early stages of development means risking increasingly tangled processes and unpredictable performance problems at the worst possible moment.

Another myth is that reactive optimization works well enough on its own. Yes, hundreds of games ship after being optimized at the last minute, but this approach usually ends with cutting features or simplifying mechanics to make up for low FPS. Reactive optimization creates a false sense of control, because fixing problems late in development takes far more time and effort than taking a systematic approach throughout the whole project.

The next myth is that optimization needs large, dedicated blocks of time, when in reality it's much more effective to work it in gradually. With practices like performance budgets, you can set limits for FPS, CPU, and GPU usage up front and organize the team's work around those numbers, and continuous monitoring with incremental code adjustments produces better results than occasional optimization pushes in the final weeks of development.

There's also a persistent belief that every optimization is justified. In reality, there are plenty of areas where programmers can sink time without seeing any obvious benefit, so only optimize what actually affects performance and weigh the potential payoff against the time the changes will take. This approach keeps you from wasting effort and keeps the focus on the bottlenecks that are really slowing the game down.

Finally, there's a misconception that performance is a single metric, when a game that "feels slow" can mean any combination of low FPS, longer response times, high CPU and GPU load, and frame rate drops. To optimize even one of these metrics effectively, developers first need to understand which ones are critical for their particular project, how they relate to each other, and what's actually holding the game back.

A systematic approach like this is the only way to avoid the common misconceptions about optimization. Will anyone actually approve such changes, though? Most likely not, because it's extremely unlikely that the project architect, tech lead, or CTO will sign off on real architectural changes, and that's not really the programmer's call to make anyway, so pushing for it tends to step on the architect's toes. Besides, changing an existing, working, well-tested system can break the systems around it, and there's no way to predict when the error will surface, only that it inevitably will. That's exactly why a developer who just joined the team can't rewrite half the engine "the right way," and what's left for them is code-level and algorithmic tweaks, which can still squeeze out a performance improvement of at least 10%.

This brings us to the reality that game development forces us to balance our "ideal" technical solutions against the practical constraints of the project. Even a programmer who sees through every optimization myth often has to work within an existing architecture they can't change and settle for local improvements at the algorithm and code level, but this approach can still deliver tangible results, such as the 10 to 15% performance gains that can make all the difference for a successful release.

Knowing where your influence ends matters, and so does choosing your battles wisely. Optimization was never just a technical skill, because it's also a team sport where every change needs to be justified, measured, and agreed upon, and in the end the best optimization is the one players actually notice, not the one that gets you a few nods in a technical chat.

Tools

Any work aimed at improving performance is wasted if you can't see what's actually happening in your code. It's like trying to repair a watch blindfolded or tune a musical instrument with your ears plugged, because you can turn the screws and pluck the strings all you want, but the result will be purely random.

In everyday life, we get immediate feedback, so if you trip, you fall, if you take a wrong turn, you may end up at a dead end, and if you add too much salt, you ruin the dish. These signals help us correct course right away and remember not to make the same mistake twice. In programming, however, things work differently, because code can execute millions of times per second, process gigabytes of data, and interact with dozens of system components, while all we see is the end result, say, an FPS counter that refuses to go above 50.

Modern software, and games in particular, can run to hundreds of thousands of lines of code stacked on top of complex operating systems, graphics drivers, and various libraries that add even more code. Without specialized analysis tools, all you can really do is guess whether the CPU can't keep up, whether the bottleneck is loading textures from disk, or whether memory is leaking somewhere. Profilers, performance monitors, and debuggers can mislead you too, but you can't do without them, because they show which functions take the longest to execute, how much memory each part of the program uses, how often the application hits the disk, and where the CPU sits idle waiting for data. Without this information you're flying blind, and with it the solution often becomes obvious, although measuring and analyzing performance correctly is its own kind of science that sometimes borders on alchemy.

Any tool that measures a program's performance will inevitably affect that performance. Some tools are light enough on their feet that they barely slow the program down, and those are called non-intrusive, while others can seriously drag down an application's performance, and those are called intrusive.

How much interference you get depends on how much data you need and how often you need it. A simple FPS counter has virtually no impact on the game, while a detailed analyzer that logs every function call and its execution time can slow things down considerably. Some tools, such as Valgrind, go even further and run the entire program inside a virtual machine to collect highly detailed information about every operation, and you can guess what that does to performance, since the program can easily run ten times slower than usual or worse.

There are several ways to measure performance, and sampling profilers are the gentlest and simplest of them. They periodically take a snapshot of the program to see which code is running at that moment, and by collecting a series of these snapshots, developers can build a statistical picture of what the program spends most of its time doing.

A more intrusive approach relies on interception tools that sit between the program and external resources, so PIX, for example, intercepts every call the program makes to the GPU through the DirectX API, while network analyzers peek at all network traffic.

Getting even more detail means adding special commands and profiling markers to the code to collect data, and this process is called instrumentation.

Choosing the right tool depends on your specific goals and on how much performance you're willing to sacrifice for a more detailed analysis. The one rule that really matters is that the tool shouldn't distort the measurements more than the problem you're hunting for, since there's little point in optimizing a function that accounts for only 1% of execution time if the profiler itself slows the program down by 50%. That's why all three types of tools are often used, each in its own circumstances.

Theory and terminology

Profilers is an umbrella term for the performance analysis tools used across most of game and software development, and a profiler's main job is to capture how the workload breaks down during execution in as much detail as the developer allows.

The classic use case is measuring CPU time, but modern profilers can track much more, including cache misses, memory allocations, disk access, thread usage, and synchronization. Depending on the level of instrumentation, they can give you either an aggregated view of the workload that shows which modules or systems put the most load on the CPU and where, or a per-frame or per-interval snapshot with the call stack and the exact distribution of work across individual instructions.

Profilers fall into two categories, general-purpose and specialized. General-purpose profilers are usually the ones built into an IDE or a platform SDK, such as the Visual Studio Profiler, and they give you a broad sense of where performance is leaking. Specialized profilers are low-level tools, such as Sony Razor, Intel VTune, PIX, or Tracy, that collect data from CPU performance counters and OS events and let you analyze code behavior with much greater precision, and only these low-level tools let developers evaluate how specific algorithmic steps or memory access patterns affect the overall performance of a piece of code.

Total time shows the cumulative execution time of a function, including all the nested calls it makes to other functions. In theory, it helps identify hotspots in an application and gives a complete picture of how much time the program spends in a particular section of code along with all its dependencies, but in practice it can give a distorted view of performance.

As part of its optimizations, the compiler may inline functions directly into the code of the calling function, which blurs the execution time of the parent function even though the inlined code is what actually does the work. This metric also doesn't account for indirect costs, such as cache pollution or data eviction, which can seriously undermine how reliable the measurement is.

For example, when you analyze functions whose performance depends heavily on their input data, such as sorting an almost-sorted array versus an unsorted one, the profiler will report an average value, which can hide real performance problems that only show up in certain use cases.

Self time measures only the time spent executing instructions inside the function itself, excluding the time spent in all the functions it calls. This helps identify the code blocks that actually do the expensive work rather than just handing it off to other functions, and functions with heavy algorithms, loops, or number crunching typically show high self time.

The ObjectUpdate() function may have a high total time because it calls all the other subsystems responsible for updating the game state, but a low self time because it doesn't do much work on its own, while a collision-physics function may show significant self time, which tells you that this particular section needs optimization. The problems here are much the same as with the previous metric, because self time can't reflect a function's actual impact on the overall performance of the system. A function may have a low self time while triggering many expensive operations through other functions, which creates a false impression of efficiency. On top of that, this metric ignores function call overhead, so if a function makes thousands of small calls, the cost of creating stack frames, passing parameters, and returning values can be significant, or even close to the actual execution time, and still stay invisible in the self-time numbers.

Another issue is "aggressive optimization," which is especially common with Clang-based compilers that inline small functions and partially embed their code at the call site. As a result, self-time measurements get distorted, because code that belongs to a different function is counted as self time for the caller (Pic. 3.2).

Picture 3. 2

The Calls metric shows how often a particular piece of code runs during a profiling session, which helps reveal how different functions are actually used in the application. Even if their individual execution times are short, functions with a high call count are good candidates for optimization, because the cumulative overhead of all those calls can be significant.

Analyzing call counts is one of the first steps in finding inefficient algorithms or unnecessary computations (with one caveat, which is covered in the note below). A function that gets called thousands of times per frame may need a whole range of optimization techniques, and a high call count can also point to recursion, resource leaks, or other architectural problems in the application (Pic. 3.3).

Picture 3.3

Overall, this is a fairly useful metric, but the call count alone doesn't show how those calls are distributed over time. A function may be called 100,000 times in a session, but if all those calls happen while a level is loading, they have no impact on gameplay performance, and in that case the profiler will show a high call count without telling you that the function sits idle while frames are being rendered. The call count can also be misleading when it comes to spotting real architectural problems, because a high number of calls may simply be the result of a well-designed architecture with lots of small, specialized functions rather than a sign of inefficiency.

NOTE

Modern compilers have gotten very good at inlining, so focusing only on call counts can lead to premature or incorrect conclusions\.

Total waste time tracks how long a function spends with its thread blocked while waiting for resources to become available, I/O operations to complete, or system events to occur (Fig. 3.4). This time doesn't reflect active execution of the function, but rather delays caused by external factors, and a high waste time can point to indirect performance problems that affect the function's overall execution time. This metric is usually analyzed when refactoring code or reducing dependencies between functions.

Picture 3.4

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

What's new in C# 15: Overview

Unicorn Developer — Tue, 20 Oct 2026 14:12:02 +0000

A new version of C# is coming soon, so we're continuing our annual tradition of reviewing its new features. The Microsoft team has prepared several highly anticipated and exciting changes for this release. Let's take a look at them.

Union types

We'll start with the most straightforward change, union types. They enable developers to combine types without relying on inheritance or interfaces where it's unnecessary or unavailable. A union is a structure that contains the complete set of supported types.

public union TestUnion(int, Version, IEnumerable<string>);

In the code above, union is the keyword, while int, Version, and IEnumerable<string> are the set of supported types.

The union types come in handy when traditional inheritance isn't an option, as it requires the types to have something in common. However, there may be cases where inheritance is impossible or makes little architectural sense. We might need to handle a specific set of types, including primitives. Normally, we'd have to specify a variable of the object type as input and then cast it to the required types within the method, including logic for handling anything unsupported. That's error-prone. Using union in this situation would solve these problems, making the code safer and easier to read.

Given the nature of the new structure, when we use union, the compiler already knows the complete list of types it can contain. So, the default branch is no longer necessary. The change protects us from a switch that misses some types while new subclasses keep falling into the default section, which can cause unpredictable program behavior.

Let's look at a more specific example. Before this update, we'd have had to write something like this to define a method for handling API responses:

public abstract record ApiResult;

public record ErrorData(string Message);
public record Success(string Data) : ApiResult;
public record ValidationError(ErrorData Data) : ApiResult;

public string Process(ApiResult result)
{
  return result switch
  {
    Success s => s.Data,
    ValidationError s => s.Data.Message,
    _ => "Unknown result"
  };
}

The ApiResult abstract class, from which specific responses inherit, is declared. So, if a new subclass appears and the developer fails to handle it, executions falls into the default branch. With a union, it works differently:

public record ErrorData(string Message);
public record Success(string Data);
public record ValidationError(ErrorData Data);

public union ApiResult(Success, ValidationError)
{ 
  public string GetData()
  {
    return this switch
    {
      Success s => s.Data,
      ValidationError s => s.Data.Message
    };
  }
}

As you can see, there's no need for a parent class just to group the types together. The behavior is also more predictable because the compiler knows at compile time exactly which types union can contain. So, if a switch doesn't handle every type in the union, the compiler issues a warning.

Moreover, the union gives developers an easier way to express patterns such as monads. It also enables implementing custom methods and properties within union, so working with all its types doesn't require writing switch.

Closed hierarchies

This change is somewhat related to union in that it also lets the compiler know exactly how many types it'll work with. It does so by preventing inheritance from a class outside the assembly where it was declared. This behavior resembles a mix of internal and sealed: it takes the scope from internal and the restriction on inheritance from sealed. This can be useful, for example, in libraries where we want to restrict inheritance from certain classes without blocking it within our own assembly. Here's an example declaration:

public closed record ClosedRecordClass;

The closed keyword marks the class as closed to inheritance. As a result, attempting to inherit from such a class in another assembly causes a compilation error. Note that, like union, a closed hierarchy supports an exhaustive switch, which enables omitting the default branch.

A few important details are worth keeping in mind. Firstly, a class marked as closed is always abstract. This also helps enable an exhaustive switch. Secondly, descendants don't automatically become closed. If we need to hide them from other assemblies, we can mark them with the internal access modifier. Thirdly, only classes (class and record class) can be closed to inheritance from another assembly. Structs don't support inheritance, while interfaces are specifically designed to be inherited from. So, adding the keyword to a struct or an interface will result in a compilation error.

Labeled break and continue

A small but quite important addition: most of us have probably run into situations where we needed to interrupt the execution of an external structure or skip to its next iteration. The classic approach would have looked something like this:

public enum WorkItemType
{
  Process,
  StopAll
}
public class WorkItem
{
  // ....
  public WorkItemType Type { get; set; }
}

public class OldLabeledBreak
{
  public void PerformAction(IEnumerable<WorkItem> workList)
  {
    bool stopProcessing = false;

    foreach (var item in workList) // #1
    {
      switch (item.Type) // #2
      {
        case WorkItemType.Process:
          // ....
          break; // break #2
        case WorkItemType.StopAll:
          stopProcessing = true;
          break; // break #2
      }

      if (stopProcessing)
        break; // break #1
    }
    // ....
  }
}

In other words, we need an additional flag so that the outer loop can exit after the inner switch finishes executing. Of course, we could use goto, but it can make the code harder to follow because the label code execution jumps to can appear anywhere. Labeled break and continue simplify this. Let's see what this method would look like now.

public void PerformAction(IEnumerable<WorkItem> workList)
{
  outer:  foreach (var item in workList) // #1
  {
    switch (item.Type) // #2
    {
      case WorkItemType.Process:
        // ....
        break; // break #2
      case WorkItemType.StopAll:
        break outer; // break #1
    }
  }
  // ....
}

As you can see, the syntax is similar to goto, while the code becomes more readable. This lets us avoid creating extra flags and checks, which can slightly reduce memory usage and also make the code more expressive. Labels can be applied with the following constructs: for, foreach, while, do, and switch.

Extension indexers

This change enables developers to define how collection elements can be accessed by index using extension indexers. For example, it's possible to implement element access with Range for IReadOnlyList. Before C# 15, we could implement this as follows:

public class OldExtensionIndexers
{
  public void Process()
  {
    IReadOnlyList<string> readOnlyList = ["val1", "val2", "val3"];
    var elem = readOnlyList.Slice(..2);
  }
}
public static class OldReadOnlyListExtensions
{
  public static IReadOnlyList<T> Slice<T>(this IReadOnlyList<T> list, 
                                          Range range)
  {
    var (offset, length) = range.GetOffsetAndLength(list.Count);
    var result = new List<T>(length);
    for (int i = 0; i < length; i++)
      result.Add(list[offset + i]);

    return result;
  }
}

While a regular extension method already solves this problem, C# 15 introduces the option to create extension indexers. So, we'll get access to elements using the familiar brackets. Let's look at how this would work in our example:

public class NewExtensionIndexers
{
  public void Process()
  {
    IReadOnlyList<string> readOnlyList = ["val1", "val2", "val3"];
    var elem = readOnlyList[..2];
  }
}
public static class NewReadOnlyListExtensions
{
  extension<T>(IReadOnlyList<T> list)
  {
    public IReadOnlyList<T> this[Range range]
    {
      get
      {
        var (offset, length) = range.GetOffsetAndLength(list.Count);
        return list.Skip(offset).Take(length).ToList();
      }
    }
  }
}

It's worth noting that if a type has its own indexer, it takes precedence over an indexer declared as an extension. The official order of precedence is as follows: explicit type indexers, implicit type indexers, explicit extension indexers, and implicit extension indexers.

Collection expression arguments

The next feature will help shorten code and make collection initialization more convenient by passing the required arguments directly to the constructor. For example, we can pass capacity and comparer. In C# 14 and earlier, we would need to write something like this:

public void ProcessList()
{
  List<string> loginList = ["login1", "login2"];

  List<string> newLoginList = new List<string>(loginList.Count);
  newLoginList.AddRange(loginList);
}
public void ProcessHashSet()
{
  HashSet<string> hashSet = new HashSet<string>
(StringComparer.OrdinalIgnoreCase);
  hashSet.Add("value 1");
  hashSet.Add("value 2");
}

The initializer supports only one option because List has just three constructors: an empty one, one that takes capacity, and one that takes a collection. Let's look at the new possible implementation:

public void ProcessList()
{
  List<string> loginList = ["login1", "login2"];

  List<string> newLoginList = [with(loginList.Count), ..loginList];
  // newLoginList.AddRange(loginList);
}
public void ProcessHashSet()
{
  HashSet<string> hashSet = [with(StringComparer.OrdinalIgnoreCase), 
    "value 1", "value 2"];
  // hashSet.Add("value 1");
  // hashSet.Add("value 2");

}

The code looks cleaner, right? Your IDE will probably even suggest this syntax and collapse everything into a single line. However, note that with must always come first; otherwise, the compiler will issue an error.

Memory safety

The final change involves reevaluating what C# considers unsafe. The language team aims to flag only code that actually accesses unmanaged memory as unsafe. In other words, using pointers will no longer automatically make code unsafe. Before C# 15, unsafe code was marked like this:

public unsafe class OldMemorySafety
{
  public int ReadMemory(byte* ptr)
  {
    return *ptr;
  }
  public int Process()
  {
    byte b = 42;
    byte* newPtr = &b;
    return ReadMemory(newPtr);
  }
}

Any use of pointers used to require the unsafe keyword. To better understand the change, let's take a look at what the code will look like in the new version:

public class NewMemorySafety
{
  public int ReadMemory(byte* ptr)
  {
    unsafe
    {
      return *ptr;
    }
  }
  public int Process()
  {
    byte b = 42;
    byte* newPtr = &b;
    return ReadMemory(newPtr);
  }
}

We no longer need to mark the class as unsafe. Instead, the keyword goes only where it's needed. In this case, dereferencing the pointer is unsafe, so it should be marked as such.

The safe keyword has also been added. It should be used when a block contains unsafe operations that are safe for the caller's context, so callers don't require the unsafe block. In other words, use safe when the compiler can't verify safety on its own. Examples include extern methods and fields in structs with explicit memory layout ([StructLayout(LayoutKind.Explicit)]).

It's also worth mentioning stackalloc. Its use is now considered unsafe when all of the following apply: it's converted to Span<T> or ReadOnlySpan<T>, it has no initializer, and it's used where SkipLocalsInitAttribute is present.

The new rules introduced by this change should be enabled separately. If you'd like to learn more, follow this link for the official instructions.

Conclusion

This year's language release has brought developers a number of fairly important features. Among them are useful additions such as union types and closed hierarchies, while several other changes simplify common coding patterns, making development little smoother once again. Some of these features may not become as popular, but that doesn't make them any less useful to certain groups of developers. Which of these changes did you find most useful? Share your thoughts in the comments!

You can read the C# 15 documentation via this link. Don't forget to check out our overviews of previous versions, here's the list:

PVS-Studio 8.01: OWASP Benchmark, JDK 25 and Go 1.27 support, and much more

Unicorn Developer — Fri, 16 Oct 2026 14:02:33 +0000

PVS-Studio 8.01 has been released. This version features expanded support for OWASP, JDK 25 and Go 1.27 support, and much more.

OWASP Benchmark for Java

In this release, we checked the Java analyzer SAST rules against the OWASP Benchmark for Java.

Evaluating the quality of security-related diagnostic rules on real-world projects can be quite challenging. We can't predict how many vulnerabilities the code will contain, so we can't determine which defects the analyzer has overlooked.

We used the benchmark to address gaps in the Java analyzer SAST capabilities, which made the tool more effective at detecting security defects.

New versions of Java and Go

With the release of PVS-Studio 8.01, we've added support for the latest platform versions. The Java analyzer now supports JDK 25, and the Go analyzer supports Go 1.27.

This enables teams to analyze projects using the latest language versions and standard libraries without delaying updates due to limitations in their analysis tools.

JDK 25 is also an LTS release, making its support particularly important for teams migrating to a new long-term support version.

Reports with analysis configuration details

The PVS-Studio_Cmd.exe utility for analyzing MSBuild projects now includes in JSON reports the project configurations used during analysis. This makes it easier to fix warnings that occur on specific platforms.

In addition, the fullhtml report generated by PlogConverter.exe now groups warnings by analysis configuration.

Expanded configuration options

This release expands the configuration options for our analyzers and utilities, making them easier to tailor to specific project requirements and environments.

The JavaScript and TypeScript analyzer now supports the max-old-space-size setting. You can find it in the pvs-settings.toml configuration file and the pvs-js.exe command-line utility. This setting enables you to specify how much memory the analyzer's Node.js server can use.

In PVS-Studio_Cmd.exe, you can now specify dependency cache paths relative to the .pvsconfig configuration file.

The C and C++ analyzer now offers more options for configuring diagnostic rules. Now, you can specify custom types as "cheap-to-copy," and configure the analyzer behavior based on the target platform.

The V719 diagnostic rule now supports additional configuration options: ignoring default branches and small enum types, specifying individual values to ignore, and setting the maximum number of constants that can be ignored.

Extended warning filtering

The Plog Converter utility for converting and filtering reports now allows you to filter diagnostic rules by CWE codes and SAST identifiers.

Breaking Change

This release includes a change that breaks backward compatibility with previous versions of the analyzer. You may need to adjust how you use the analyzer due to these changes.

The PVS-Studio installer for Windows now returns exit code 100 if Visual Studio plugin installation fails. We also added the skipVSIXInstallErrorCode flag to disable the non-zero exit code in this case.

New diagnostic rules

Java

V5341. OWASP. A cookie was created without enabling the 'Secure' attribute. This may lead to the exposure of sensitive data.
V5342. OWASP. Potentially tainted data is stored in an object that can be used as a source of trusted data.
V5343. OWASP. A cryptographically weak random number is used for sensitive data.

Articles

Here's the traditional roundup of posts from our blog! Over the past two months, we've published articles where we looked for bugs in the popular C# ORMs, RepoDB and SqlSugar, reviewed VSCode source code, explored the new features of Java 27, found bugs in the Create mode, and much more. The full list is below:

C and C++

The worst programming language of all time /s

Csharp

What popular ORMs for C# hide: Let's check RepoDB and SqlSugar

Java

Webinars

Let's make a programming language. Variables

We continue building our own programming language from scratch. In this video, we'll take the next step by adding variables to the language.

So far, our programs have consisted of a single expression built from smaller language constructs. Now it's time to evolve the language. Instead of parsing a single expression, we'll introduce a list of declarations, allowing our language to support variable declarations and laying the groundwork for more complex programs.

During the video, Yuri will walk through the implementation step by step, showing how variables are represented and processed in our language, and how to add this functionality to your language in C++.

This video is designed for developers who want to understand how programming languages work under the hood—not just how to use them.

Go-Go-Gadg...Error? A closer look at the mistakes Go developers make!

Mistakes happen in Go code just like in any other language: typos, duplicates, broken condition checks, and so on.

But why do they still slip through? After all, many teams use tools like go vet, which catches all of this perfectly well... right?

In this webinar we covered:

Common mistakes in Go code, straight from well-known projects;
Errors that standard tools and approaches fail to catch, and how to handle them.

Let's make a programming language. Functions

We continue building our own programming language from scratch.

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 video, we 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.

Let's make a programming language. Evaluator

We're reaching the final stage of our journey of building a programming language in C++!

So far, we've created a lexer, a parser, and an AST. Now it's time to make our language do what it was designed to do—evaluate expressions.

In this webinar, we'll explore how to represent the results of computations in our language and learn how to evaluate expressions step by step. By the end of the session, we'll bring all the pieces together and complete our own programming language.

Go vet can't go: How to create your own Go analyzer?

A static analyzer is a powerful dev tool, and any Go developer who has worked with go vet knows it. But what if its capabilities aren't enough? Would you look for a new tool, or... build your own?

In this live talk, PVS-Studio's Developer Advocate walks through Go's built-in tools and code-parsing capabilities, explains the basics of static analysis, unpacks what a semantic model is, shows how to build a syntax tree, and much more.

The end goal? Build your own static analyzer, tailored to catch what matters most in your projects.

Bugbusters

This is the first episode of our new podcast, Bugbusters. Our guest is Nathan Baggs, a content creator and YouTuber. We discussed whether it's worth learning C++ in 2026, how the language is evolving, what it's used for, and what its drawbacks are. We hope you enjoy this episode! We look forward to your comments!

Conclusion

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

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

When copy-paste goes wrong: Bugs in structurally isomorphic Go code

Unicorn Developer — Tue, 13 Oct 2026 14:20:32 +0000

You might've done this many times: you found code in a project that seemed like a good fit for your task, copied it, replaced the variables or function calls with the ones you needed, and then got behavior you didn't expect when you ran the code. It's likely that you missed something while making those changes. This is exactly how the errors described in this article occur.

Introduction

PVS-Studio 8.00 was recently released, introducing several new major features, including the Go analyzer that comes with several new and cool diagnostic rules.

It includes a rule that detects one of the trickiest types of copy-paste bugs, the kind that can easily slip past a regular code review. Okay, now let's take a look at the code:

if process.ProcessName != nil && 
   (len(*process.ProcessName) == 0 ||
   len(*process.ProcessName) > common.NameFieldMaxLength) {

  return kit.CCError.CCErrorf(common.CCErrCommParamsInvalid,        
                              common.BKProcessNameField)
}
....
if process.FuncName != nil && 
   (len(*process.FuncName) == 0 ||
   len(*process.ProcessName) > common.NameFieldMaxLength) {

  return kit.CCError.CCErrorf(common.CCErrCommParamsInvalid, 
                              common.BKFuncName)
}

You've probably noticed that the expressions in both if statements consist of the same checks, but they aren't completely identical: the first one uses process.ProcessName, while the second one uses process.FuncName in the same positions. Or... does it?

The last checks suspiciously break this pattern: they're exactly the same, and both use the process.ProcessName field. Based on the logic the code has consistently followed so far, the check in the second if should have used a different field, process.FuncName.

Since such typos can easily slip past manual review, the best solution is to delegate the task of catching them to a static analyzer. But how can we teach a program to compare similar yet distinct code fragments and use those comparisons to detect bugs the way humans do? Is AI necessary for that? In the rest of this article, we'll explore these questions by looking at how the diagnostic rule works in PVS-Studio for Go.

How does the analyzer find these bugs?

Modern AI models can indeed detect such bugs. However, integrating artificial intelligence into a static analyzer for such a purpose is too expensive and resource-intensive.

Fortunately, we don't need AI here. We can handle the task with a relatively simple heuristic algorithm. We'll take a closer look at how it works later, but first, let's go over a few basic concepts from static code analysis:

Statements are the elements of code that form its skeleton and describe the execution flow (if, switch, for, and {...} blocks).
Expressions are code elements that manage data (function calls, variables, and operators).
Nodes is a general term for statements, expressions, and other types of code elements.
Abstract Syntax Tree (AST) represents code as a hierarchical structure where some elements, like folders in a file system, contain other elements. An AST contains the same information you can get from the code itself, but its structured format makes it better suited for program analysis.

If you're interested in delving deeper into static analysis, we have the perfect article for you.

Well, now that we have enough context, we're ready to face the ~~boss~~ algorithm. Here's how the V8033 diagnostic rule in PVS-Studio's Go analyzer works:

Within a function, the analyzer takes individual statements and groups of statements, separated by blank lines (hereinafter referred to as code fragments) and builds a simplified AST for them. Unlike a regular AST, it contains only the information needed to describe the code structure and omits specific names of variables, functions, and other semantic information.
The fragments are grouped by their simplified AST. This is how fragments with similar structure are identified, even though they may still differ in their details (for example, in the variables they use).
Within each group, the fragments are paired and compared with one another. Let's look at how the algorithm works for a single pair. For convenience, let's call the two fragments in one pair A and B.
The analyzer identifies the variables that appear in both A and B (common variables) as well as the variables that appear in only one of the fragments (specific variables).
Let's assume that A is higher in the code than B. If one of the common variables occurs less frequently in B than in A, but still at the same relative positions, the uses of that variable in B are treated as potential typos.
Next, a replacement candidate is sought among the B variables. This variable must be used in the same relative position as the previously considered general variable in A, but not in B.
If the analyzer finds such a candidate, it performs a series of final checks to determine whether the variables are interchangeable. If all the checks pass, the developer receives warnings about possible typos in the code.

Of course, this is just a conceptual outline. A significant amount of important logic remains behind the scenes, especially the logic that filters out false positives. Without it, the diagnostic rule would be far less useful.

It is only 5% of the task to create the diagnostic. It's not hard for the analyzer to complain about suspicious code, it's much harder to not complain about the correct code. We spend 95% of our time "teaching" the analyzer to detect various programming techniques, which may seem suspicious for the diagnostic, but in reality they are correct.

From the article "How PVS-Studio does the bug search: methods and technologies"

Now that we've taken a quick look at how the analyzer works, let's exercise in looking for similar errors on our own.

Find an error

I invite you to challenge yourselves by finding errors in this code, which was taken from real open-source projects. The closer you get to the end, the harder the examples become.

Are you up for the challenge? Let's get started, then!

Yao Agents

Yao Agents is an open-source platform for creating and running autonomous AI agents. Its key feature is that the agents run directly on users' devices, while all operations are centralized and controlled via a single interface.

We found this code in the v1.0.0-rc15 release:

func Generate(option Option) (string, string) {
  if option.Width == 0 {
    option.Width = 240
  }

  if option.Height == 0 {
    option.Width = 80
  }

  if option.Length == 0 {
    option.Length = 6
  }

  if option.Lang == "" {
    option.Lang = "zh"
  }
  ....
}

The analyzer's hint
V8033 Two similar code fragments were found. The second fragment may contain a typo: the "option.Height" variable should be used instead of the "option.Width". captcha.go 48

CDS

CDS is an enterprise-grade platform for automating DevOps processes, continuous integration (CI), and continuous delivery (CD).

We found this code in the 0.54.1 release:

if conf.GraylogFieldCDSServiceName != "" {
  extra["CDSName"] = conf.GraylogFieldCDSServiceName
}
if conf.GraylogFieldCDSServiceName != "" {
  extra["CDSService"] = conf.GraylogFieldCDSServiceType
}
if conf.GraylogFieldCDSVersion != "" {
  extra["CDSVersion"] = conf.GraylogFieldCDSVersion
}
if conf.GraylogFieldCDSOS != "" {
  extra["CDSOS"] = conf.GraylogFieldCDSOS
}
if conf.GraylogFieldCDSArch != "" {
  extra["CDSArch"] = conf.GraylogFieldCDSArch
}

The analyzer's hint
V8033 Two similar code fragments were found. The second fragment may contain a typo: the "conf.GraylogFieldCDSServiceType" variable should be used instead of the "conf.GraylogFieldCDSServiceName". log.go 107

BFE

BFE is a high-performance, application-level load balancer and reverse proxy server.

We found this code in the 1.8.4 release:

if cfg.Basic.WasmPluginPath == "" {
  ....
  cfg.Basic.WasmPluginPath = "mod_wasm"
}
cfg.Basic.WasmPluginPath = bfe_util.ConfPathProc(....)

if cfg.Basic.DataPath == "" {
  ....
  cfg.Basic.WasmPluginPath = "mod_wasm/wasm.data"
}
cfg.Basic.DataPath = bfe_util.ConfPathProc(cfg.Basic.DataPath, 
                                           confRoot)

The analyzer's hint
V8033 Two similar code fragments were found. The second fragment may contain a typo: the "cfg.Basic.DataPath" variable should be used instead of the "cfg.Basic.WasmPluginPath". conf_mod_wasmplugin.go 63

Hertz

Hertz is a high-performance HTTP framework written in Go by ByteDance (the creators of TikTok), designed for building high-load microservices. It combined the concepts of popular Go frameworks (Gin, FastHTTP) with ByteDance's internal requirements.

We found this code in the 0.10.6 release:

if goOptMapAlias[sb.Scope.GetOptions().GetGoPackage()] != "" {
  reqName = goOptMapAlias[sb.Scope.GetOptions().GetGoPackage()] + 
            "." + inputGoType.GoIdent.GoName
}
if goOptMapAlias[sb.Scope.GetOptions().GetGoPackage()] != "" {
  respName = goOptMapAlias[st.Scope.GetOptions().GetGoPackage()] + 
             "." + outputGoType.GoIdent.GoName
}

The analyzer's hint
V8033 Two similar code fragments were found. The second fragment may contain a typo: the "st" variable should be used instead of the "sb". ast.go 233

Nuclei

Nuclei is a modern, high-performance vulnerability scanner that uses simple YAML-based templates. It enables users to create their own vulnerability detection scenarios that simulate real-world conditions, which eliminates false positives.

We found this code in the 3.11.1 release:

for _, tag := range config.ExcludeTags {
  for _, val := range splitCommaTrim(tag) {
    if _, ok := filter.block[val]; !ok {
      filter.block[val] = struct{}{}
    }
  }
}
for _, tag := range config.Severities {
  if _, ok := filter.severities[tag]; !ok {
    filter.severities[tag] = struct{}{}
  }
}
....
for _, tag := range config.ExcludeProtocols {
  if _, ok := filter.excludeTypes[tag]; !ok {
    filter.excludeTypes[tag] = struct{}{}
  }
}
for _, id := range config.ExcludeIds {
  for _, val := range splitCommaTrim(id) {
    if _, ok := filter.block[val]; !ok {
      filter.excludeIds[val] = struct{}{}
    }
  }
}

The analyzer's hint
V8033 Two similar code fragments were found. The second fragment may contain a typo: the "filter.excludeIds" variable should be used instead of the "filter.block". tag_filter.go 434

LakeFS

LakeFS is an open-source data version control system for managing data stored in an object storage system. It enables Git-like operations like branching, committing, merging, and rolling back for large-scale data, stored in systems including Amazon S3, Azure Blob Storage, and Google Cloud Storage, as well as on other S3-compatible object storage platforms.

We found this code in the 1.86.0 release:

usersKey := model.GroupUserPath(groupID, "")

it, err := kv.NewSecondaryIterator(....)

if err != nil {
  return err
}
defer it.Close()
for it.Next() {
  entry := it.Entry()
  user := entry.Value.(*model.UserData)
  ....
}
if err = it.Err(); err != nil {
  return err
}

policiesKey := model.GroupPolicyPath(groupID, "")

itr, err := kv.NewSecondaryIterator(....)

if err != nil {
  return err
}
defer it.Close()
for itr.Next() {
  entry := itr.Entry()
  policy := entry.Value.(*model.PolicyData)
  ....
}
if err = itr.Err(); err != nil {
  return err
}

The analyzer's hint
V8033 Two similar code fragments were found. The second fragment may contain a typo: the "itr" variable should be used instead of the "it". service.go 476

Vault

Vault is an open-source (BSL) tool for centralized secret management, data encryption, and for the protection of confidential information in cloud and hybrid infrastructures.

We found this code in the 2.0.4 release:

for name, crl := range h.CRLs {
  ....
  ratio := time.Duration(
    (int64(total) * int64(h.CRLExpiryPercentage)) / int64(100)
  )
  if used >= ratio {
    expWhen := crl.ThisUpdate.Add(ratio)
    ret.Status = ResultCritical
    ret.Message = fmt.Sprintf(
      ...., 
      crl.NextUpdate.Format("2006-01-02"), 
      h.CRLExpiryPercentage,   
      crl.ThisUpdate.Format("2006-01-02"), 
      expWhen.Format("2006-01-02")
    )
    ....
  }

  results = append(results, &ret)
}

for name, crl := range h.DeltaCRLs {
  ....
  ratio := time.Duration(
    (int64(total) * int64(h.DeltaCRLExpiryPercentage)) / int64(100)
  )
  if used >= ratio {
    expWhen := crl.ThisUpdate.Add(ratio)
    ret.Status = ResultCritical
    ret.Message = fmt.Sprintf(
      ...., 
      crl.NextUpdate.Format("2006-01-02"),
      h.CRLExpiryPercentage, 
      crl.ThisUpdate.Format("2006-01-02"), 
      expWhen.Format("2006-01-02")
    )
    ....
  }

  results = append(results, &ret)
}

The analyzer's hint
V8033 Two similar code fragments were found. The second fragment may contain a typo: the "h.DeltaCRLExpiryPercentage" variable should be used instead of the "h.CRLExpiryPercentage". pki_crl_validity_period.go 195

Conclusion

Did you spot all the errors without looking at the hints? If so, that's great! If not, don't worry—that's where a static code analyzer comes into play!

By the way, you can download it from our official website and try it for free on your own projects.

In addition to the Go analyzer, PVS-Studio 8.00 brought several other exciting features, including an analyzer for JavaScript and TypeScript. You can find more details about them in our article.

Happy coding!

How we made JavaScript analyzer understand control flow

Unicorn Developer — Fri, 09 Oct 2026 12:31:28 +0000

We recently added JavaScript/TypeScript support to PVS-Studio analyzer. From its first release, the analyzer can detect control-flow bugs in code. In this article, we'll learn about the control flow graph (CFG), how we've implemented it, and why it's useful.

A Control Flow Graph?

I've touched on this topic before, in my series on taint analysis in Java, but let's quickly recap it here. A static analyzer starts by converting source code into an abstract syntax tree (AST). It almost completely mirrors the structure of the code as you write it in the editor. That makes it a poor fit for anything involving control flow analysis, such as finding unreachable code. It's possible to write a check for unreachable code on the AST, but:

this would be unreliable in corner cases;
this wouldn't scale well to similar rules;
this would be hard to maintain. Every bug fix or new language version would mean revisiting all of these diagnostic rules.

The Control Flow Graph (CFG) exists to address these issues; it maps out all possible execution paths in a program.

The CFG consists of three components:

entry and exit nodes;
Basic blocks nodes, each containing linear instructions;
- Each basic block ends with a terminator (or with nothing). A terminator is a special instruction that determines specific semantics for the execution flow: branching, break/continue, and so on.
Edges between nodes that represent possible control flow transitions.

How did we do it?

Common CFG

In our article on developing the JavaScript/TypeScript analyzer, we mentioned that the tool includes not only a syntax tree for each specific language, but also a common one for multilingual analysis. We named it CAT (Common Abstract Tree).

No other languages have joined JavaScript/TypeScript yet, but we've already made the CFG extensible: the core engine doesn't depend on any specific language. We define a set of multiple semantics and just combine them like building blocks into a CFG for a specific language we need. It'll save time when it comes to supporting other languages in the future.

Here are two examples of language-specific semantics for JavaScript/TypeScript:

The try blocks in which exceptions are untyped, and only one catch is allowed.
Labels are attached to a specific statement, and you can jump to them only from the break statement nested within that statement. You can also jump to the label using continue if it is inside a loop.

Testing approach

Checking that a CFG is correct is quite an adventure of its own. The first thing that comes to mind is to serialize the graph in Graphviz (or some other way), check it visually, and save it as a reference. Spoiler: that was a trap, and we fell into it. Here's why it doesn't work:

The graph changes constantly during development. You end up manually rewriting the failing tests or burning through AI agents' tokens.
It's very easy to miss a bug in the reference. If people didn't make mistakes, the static analysis industry wouldn't exist.
A neat-looking topology doesn't guarantee that the graph captures the full semantics of the control flow.

So we changed the approach and wrote a mini-interpreter for our CAT, driven by the CFG. The idea is simple: if our interpreter, after traversing the graph, produces the same result as the JavaScript interpreter, the graph is constructed correctly. We verify this with a simple assertion API, like this:

@Test
void branching() {
    EvaluationAssert.evaluate("branching")
                    .withParam("param", true)
                    .expect("a", 2);

    EvaluationAssert.evaluate("branching")
                    .withParam("param", false)
                    .expect("a", 0);
}

This test runs the interpreter and compares the execution results with the reference, which you can get by running the TypeScript code beforehand:

function branching(param: boolean) {
    let a = 1;
    if (param) {
        a++;
    } else {
        a--;
    }
}

We didn't have to implement the entire JavaScript specification—a tiny subset was enough. Cutting corners actually worked in our favor: if you don't clear variables when they go out of scope, you can inspect the state of the code at different points.

Another nice bonus: the minimalist interpreter is a full-fledged proof of concept for graph processing. It can serve both as a reference for using the API and as groundwork for upcoming data-flow analysis.

The result is a working graph builder for JavaScript/TypeScript that constructs each graph in a single AST traversal. It's quite fast: for React, all graphs are built in a quarter of a second.

What it can catch today

Linear code

The most basic typos, the kind the AST could catch too, come first, of course:

if ( curveLengths[ i ] >= d ) {
    diff = curveLengths[ i ] - d;
    curve = this.curves[ i ];
    var u = 1 - diff / curve.getLength();
    return curve.getPointAt( u );
    break;
}

The PVS-Studio warning: V7039 Unreachable code detected. Control flow never reaches this statement. three.js 29417.

That's the graph built by the analyzer:

What are merge nodes?
A merge node is an auxiliary node used during graph construction. It makes the graph easier to work with, because nodes with multiple predecessors are cumbersome to handle. The analysis doesn't use merge nodes (yet).

In the example above, the merge has only one incoming edge instead of two, as in the previous scheme, because the true branch contains a return, which requires an edge to be created straight to the exit node.

The graph shows clearly no path lead to break, so the analyzer marks it as unreachable.

It's unlikely that this error has any effect, and the unreachable break is probably just redundant. But here's the interesting part: this file is the Three.js library, copied into Juice Shop, and we couldn't find the same error in the current Three.js repository.

By the way, here's a classic bug involving automatic semicolon insertion (ASI):

function foo() {
    return // asi happens here
        this.bar
}

The analyzer catches it the same way. The inserted ; creates a terminator in the block containing the return and moves this.bar to the next block:

Conditions

Phaser gives us a good example of "defensive programming":

if (!childA.parentContainer && !childB.parentContainer)
{
    return this.displayList.getIndex(childB)
      - this.displayList.getIndex(childA);
}
else if (childA.parentContainer === childB.parentContainer) {
// more branches ending with return statements here
} else
{
    var listA = childA.getIndexList();
    var listB = childB.getIndexList();
    var len = Math.min(listA.length, listB.length);

    for (var i = 0; i < len; i++)
    {
        var indexA = listA[i];
        var indexB = listB[i];

        if (indexA === indexB)
        {
            continue;
        }
        else
        {
            return indexB - indexA;
        }
    }
    return listB.length - listA.length;
}
//  Technically this shouldn't happen, but ...
// eslint-disable-next-line no-unreachable
return 0;

The PVS-Studio warning: V7039 Unreachable code detected. Control flow never reaches this statement. InputPlugin.js 2981

There were more else-if branches, but I removed them to keep the example short and to the graph small:

If you peruse the comment and look at the code, the programmers' concern starts making sense: the logic above is complex, merging more than 5 branches, each of which terminates the execution flow. Devs decided to play it safe, not even trusting ESLint. Following its trail, the analyzer saw from the graph's topology that there is simply no path to return 0.

Loops

As a bonus, we also get the ability to identify loops that run infinitely or, conversely, only once. I found such a case in the already mentioned Three.js:

loop:
for (var pos = 0; pos < limit; pos++) {
    for (; pos < limit; pos++) {                 // <=
        for (var k = 0; k < needleLength; k++) {
            if (haystack[pos + k] !== needle[k]) {
                continue loop;
            }
        }

        return pos;
    }
}

The PVS-Studio warning: V7039 Unreachable code detected. Control flow never reaches this statement. opentype.module.js 6109.

Here is the control flow graph:

The diagnostic rule warns that the increment of the pos variable in the loop is unreachable. Looking at the code, you can easily see that all the branches indeed terminate the second for loop, so it runs only once. The graph confirms this—there is no path to the increment.

This code originally came from OpenType, but the copied dependency was removed at the time of the writing.

Exception handling

Nested try blocks and execution flow interruptions from finally are rare andoften considered a code smell, so I couldn't find any instances in open-source code right away.

Still, this was one of the trickiest cases to handle due to the complexity of the try-catch-finally semantics. The analyzer has to handle several things:

Check if the try block contains a catch, a finally, or both;
Track explicit throw statements and also handle where implicit exceptions lead.
Override the control flow interruption within the finally block when the control flow interruption occurs in try or catch.
Propagate the control flow interruption that occurs in finally up through the try block.
Cover many other edge cases and their combinations.

Since I still want to show this case, here's a synthetic example:

function tryCatchFinallyCase() {
    try {
        try {
            throw new Error("Whoops");
        } finally {
            console.log("inner")
        }
        return true // V7039
    } finally {
        console.log("outer")
    }
    return false; // V7039
}

For this function, the analyzer will construct the following graph:

The diagram clearly shows that the edges themselves carry information about which operation they "remembered" before exiting the function. The analyzer also identifies the unreachable return nodes.

What's next?

We've walked through the errors that the analyzer can now detect thanks to control flow graph support. It has already proven its capabilities, making it fairly straightforward to implement diagnostic rules V7039 (unreachable code) and V7040 (infinite recursion) by the time PVS-Studio 8.00 was released. Beyond adding new diagnostic rules, other opportunities are opening up:

Extend the CFG construction by applying it to short-circuit expressions.
Find dead code as well as unreachable code, using conditional constant propagation. Once we have laid the groundwork for the data-flow analysis engine, we can implement taint analysis (tracking tainted data throughout the program).
Extend the same engine to other kinds of data-flow analysis, such as detecting null dereference, division by zero, and so on.

In short, CAT grows the analyzer wider, and the CFG lets us grow it deeper. The ground for developing the new analyzer is now even more productive.

Wrap-up

That's the end of the brief overview of the analyzer's technology. I hope you enjoyed seeing how static analysis works and what kinds of errors control flow analysis can find. If you've worked with similar technologies, share your experience in the comments. I'd love to read your stories. The promised article on the inner workings of CAT is still on the way, along with more articles on code quality. Follow us to stay tuned:

PVS-Studio in X;
monthly newsletter;
my personal blog.

Go vet can't go: How to create your own Go analyzer?—Key points

Unicorn Developer — Thu, 08 Oct 2026 11:48:24 +0000

Why build a custom analyzer?

Go already includes static analysis via go vet, but it can't detect every issue. Real-world projects contain errors that may look obvious to a developer yet remain invisible to standard tools. Other tools can also produce false positives or miss errors. A custom analyzer lets you focus on problems specific to your code and control exactly what the tool checks. The trade-off is that it needs to be maintained and tested. The diagnostic rules also need to be refined to minimize false positives and negatives.

Syntax and semantics

Static analysis relies on two main sources of information: syntax and semantics. The syntax tree shows the code structure and can reveal issues based on this structure. However, some cases require understanding what expressions and identifiers mean. Go/types provide this semantic information, including expression types and the declarations they refer to.

Building an analyzer

The Go analysis framework handles routine work such as collecting files, parsing them, and checking types. The analysis pass provides parsed files, type information, the current package, diagnostic rules, and source positions. A rule can then traverse the syntax tree, inspect relevant nodes, and report issues to the user.

From rule to diagnostic

The speaker demonstrates this process with a rule that detects empty if statements and then applies the same approach to a more complex value-receiver case. The result is a custom diagnostic rule tailored to a specific problem that existing tools may miss.

Want more?

If you want to watch the full talk, follow this link.

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

See ya!

I found some bugs in Create mod and checked them in Minecraft

Unicorn Developer — Tue, 29 Sep 2026 13:29:42 +0000

This article covers bugs in Create, one of the most popular Minecraft mods. Let's see how they impact the game and then submit pull requests with the necessary fixes.

Introduction

Create is a Minecraft mod that adds shafts, gears, and other mechanical components. You can combine them to build machines powered by rotational force, from a simple windmill to a fully automated cake factory.

The mod is hugely popular: it has more than 206 million downloads on CurseForge alone. That doesn't even include Modrinth, and the mod keeps getting updates for new versions of the game. I'm pretty sure almost everyone who opened the article has played this mod.

Let's check the project

Some important info

To check the project, I used PVS-Studio static analyzer. The article author is one of its developers.
You'll see code examples as you read. Most of them have been shortened to avoid overwhelming the reader. I've also put an ellipsis to mark the shortened code: "....".
At the time of the check, the latest revision was the 87b3c6a commit. I checked it using the static analyzer.
All analyzed source files and any conclusions based on other source files, include a permanent link that you can use to find them.
The article includes only the bugs that the author found interesting (yes, it's a matter of personal taste). If you want to see the rest, you can always download the analyzer and check the project yourself.

Ctrl + V doesn't work

The SchematicEditScreen.java(130) file

Let's take a look at the menu for pasting a schematic.

What's a schematic?
A schematic is a part of the game world saved as a separate file. This lets you move your house from one world to another, for example.

public boolean keyPressed(int code, ....) {
  if (isPaste(code)) {
    String coords = minecraft.keyboardHandler.getClipboard();
    if (coords != null && !coords.isEmpty()) {
      coords.replaceAll(" ", "");             // <=
      String[] split = coords.split(",");
      if (split.length == 3) {
        boolean valid = true;
        for (String s : split) {
          try {
            Integer.parseInt(s);
          } catch (NumberFormatException e) {
            valid = false;
          }
        }
        if (valid) {
          xInput.setValue(split[0]);
          yInput.setValue(split[1]);
          zInput.setValue(split[2]);
          return true;
        }
      }
    }
  }
  ....
}

The PVS-Studio warning:

V6010 The return value of function 'replaceAll' is required to be utilized. SchematicEditScreen.java 130

The idea is simple: the player copies the coordinates, presses Ctrl + V in a dedicated window, and the fields fill in automatically.

But the replaceAll call marked // <= serves no purpose. Strings in Java are immutable, so the method doesn't modify the original string; it returns a new one instead. The new string is immediately discarded, leaving the spaces instead.

The code then splits the string by commas, leaving a space at the beginning of the second and third elements, and Integer.parseInt(" 67") throws a NumberFormatException. As a result, the fields remain empty.

After opening the menu, I saw the expected behavior:

-156, 67, 204 doesn't work;
-156,67,204 works.

The fix fits on a single line. We just add an assignment before the replaceAll operation:

coords = coords.replaceAll(" ", "");

Unnecessary maximum

The ScheduleScreen.java(557) file

for (List<ScheduleWaitCondition> list : entry.conditions) {
  int maxWidth = getConditionColumnWidth(list);
  for (int i = 0; i < list.size(); i++) {
    ScheduleWaitCondition scheduleWaitCondition = list.get(i);
    Math.max(maxWidth, renderInput(....));   // <=
    scheduleWaitCondition.renderSpecialIcon(....);
  }
  AllGuiTextures.SCHEDULE_CONDITION_APPEND.render(
    graphics, 
    xOffset + (maxWidth - 10) / 2,
    29 + list.size() * 18
  );
  xOffset += maxWidth + 10;
}

The PVS-Studio warning:

V6010 The return value of function 'max' is required to be utilized. ScheduleScreen.java 557

The analyzer warning clearly explains the error: the result of the Math.max(....) call isn't written anywhere.

I looked through the commit history, expecting to find some traces of refactoring. I thought the developers might have moved the width calculation to a separate method and removed the assignment to maxWidth but left the Math#max call untouched. There was nothing like that, though. The file first appeared on February 1, 2022, in a single 941-line commit, and the Math#max call without an assignment had been there all along. The original initialization of maxWidth with a call to getConditionColumnWidth() was there too.

What would change if the devs added maxWidth = Math.max(....)? Nothing. The column width where the text appears (see the image below) is calculated in advance with some extra room: getConditionColumnWidth() goes through the entire column and takes the maximum width, so no line can extend beyond it. I checked this using the debugger: in every case I was able to test, it returned the same width. So, the code is searching for the maximum of two identical numbers.

The line didn't break over time, nor was it affected by any refactoring. From day one, it had done nothing—for four years and through several updates to newer Minecraft versions.

I'd suggest removing the unnecessary wrapper and leaving renderInput on its own.

Ignore error handling

The MechanicalCrafterBlockEntity.java(535) file

First of all, let me show you what the mechanical crafter looks like:

Image explanation
In vanilla Minecraft, players craft items at a crafting table by manually placing ingredients in specific slots. A mechanical crafter does the same thing automatically. You build a grid from several blocks, with each block corresponding to one slot in the recipe, and place the required ingredient in each one. The screenshot shows the recipe for an iron pickaxe: three ingots in the top row and two sticks down the middle.

The arrows on the front indicate the route. The crafters pass items from one to another along the chain until everything reaches the final block. That's where the recipe gets assembled, and the finished item moves on to a conveyor belt or into a chest.

The whole system runs on rotational power, so it needs a drive connected to the side. In the screenshot, a creative motor powers the grid.

Let's take a look at a method in its logic:

protected void continueIfAllPrecedingFinished() {
  List<MechanicalCrafterBlockEntity> preceding = 
    RecipeGridHandler.getPrecedingCrafters(this);

  if (preceding == null) { // <=
    ejectWholeGrid();
    return;
  }

  for (MechanicalCrafterBlockEntity blockEntity : preceding)
    if (blockEntity.phase != Phase.WAITING)
      return;

  phase = Phase.ASSEMBLING;
  countDown = 1;
}

The PVS-Studio warning:

V6007 Expression 'preceding == null' is always false. New returns not-null reference. MechanicalCrafterBlockEntity.java 535

The getPrecedingCrafters method returns the crafters that come earlier in the chain. In other words, the ones that feed items into the current crafter. It can never return null. A list is created at the start, and both method exits return it. Even if the block isn't a crafter, the method returns an empty list:

public static List<MechanicalCrafterBlockEntity> getPrecedingCrafters(
  MechanicalCrafterBlockEntity crafter
) {
  BlockPos pos = crafter.getBlockPos();
  Level world = crafter.getLevel();
  List<MechanicalCrafterBlockEntity> crafters = new ArrayList<>();
  BlockState blockState = crafter.getBlockState();

  if (!isCrafter(blockState))
    return crafters;

  ....
  return crafters;
}

This means the branch with ejectWholeGrid() is unreachable. The preceding list can never be null, but it can be empty, and often is. What if we replace the check with isEmpty() and test it in the game? Let's see what happens.

Before the fix:

After the fix with isEmpty:

The video shows that, before the fix, items entering the loop were passed from one crafter to another indefinitely. That could potentially cause trouble and break someone's factory :)

However, after the check was replaced with isEmpty(), the loop didn't even have a chance to form. The method determined that there was nowhere else to expect items from, so it ejected them.

However, as soon as I added two more crafters to the chain, the fix stopped working:

Two options are possible here. Either the mechanical crafter needs to detect loops differently, then simply replacing the check with isEmpty() isn't enough. Or this looping behavior isn't a bug at all. In that case, we can just remove the null check.

The logging crash

The TrainRelocationPacket.java(52) file

Here's the client-server train movement package handler:

public void handle(ServerPlayer sender) {
  Train train = Create.RAILWAYS.trains.get(trainId);
  Entity entity = sender.level().getEntity(entityId);

  String messagePrefix = sender.getName()
      .getString() + " could not relocate Train ";

  if (
    train == null || // <=
    !(entity instanceof CarriageContraptionEntity cce)
  ) {
    Create.LOGGER.warn(messagePrefix + train.id.toString()
        .substring(0, 5) + ": not present on server");
    return;
  }

  if (!train.id.equals(cce.trainId))
    return;

  ....
}

The PVS-Studio warning:

V6008 Potential null dereference of 'train'. TrainRelocationPacket.java 52

The condition triggers in two cases: either the train can't be found, or the entity is of the wrong class. The second case is fine: it logs a proper warning. However, in the first case, the code accesses train.id when train is null.

The funny part is that the message we're trying to log ends with not present on server. The branch was created for a missing train, but it fails because of it.

The packet comes from the client, meaning it chooses the train ID. A modified client build can send requests to transfer nonexistent trains and make the server fill its log with stack traces.

The server won't crash: Create registers its packets so they execute safely, and even if an exception occurs, it gets logged, while the packet simply goes unhandled.

We can fix this by including the identifier in the package:

messagePrefix + trainId.toString().substring(0, 5)

The two-state theory

The MechanicalMixerBlockEntity.java(238) file

protected List<Recipe<?>> getMatchingRecipes() {
  List<Recipe<?>> matchingRecipes = super.getMatchingRecipes();  
  if (!AllConfigs.server().recipes.allowBrewingInMixer.get())
    return matchingRecipes;

  Optional<BasinBlockEntity> basin = getBasin();
  if (!basin.isPresent())
    return matchingRecipes;

  BasinBlockEntity basinBlockEntity = basin.get();
  if (basin.isEmpty()) // <= 
    return matchingRecipes;

  IItemHandler availableItems = level.getCapability(
  Capabilities.ItemHandler.BLOCK, 
  basinBlockEntity.getBlockPos(), null
  );

  if (availableItems == null)
    return matchingRecipes;

  for (int i = 0; i < availableItems.getSlots(); i++) {
    ....
  }

  return matchingRecipes;
}

The PVS-Studio warning:

V6007 Expression 'basin.isEmpty()' is always true. MechanicalMixerBlockEntity.java 238

Here, basin.isEmpty() can never return true, so return in this branch is unreachable. Most likely, the developers meant to check basinBlockEntity rather than Optional.

This doesn't affect gameplay in any way. Further down, the code has other checks that work with the same block, and if the basin is empty, either the loop doesn't run or availableItems is null.

But a dead if is more dangerous than it looks. It's a safeguard that doesn't really protect against anything. Rewriting the checks below leaves a hole that no one will think to look for because the check is kind of there.

Method contracts must be followed

The Contraption.java(230) file

public static Contraption fromNBT(Level world, CompoundTag nbt, 
                  boolean spawnData) {
  String type = nbt.getString("Type");
  Contraption contraption = ContraptionType.fromType(type);
  contraption.readNBT(world, nbt, spawnData);
  ....
}

Can you see the error? What if we take a look inside ContraptionType#fromType?

/**
 * Lookup the ContraptionType with the given ID, 
 * and create a new Contraption from it if present.
 * If it doesn't exist, returns null.
 */
@Nullable
public static Contraption fromType(String typeId) {
  ContraptionType legacy = AllContraptionTypes.BY_LEGACY_NAME
                        .get(typeId);
  if (legacy != null) {
    return legacy.factory.get();
  }
  ResourceLocation id = ResourceLocation.tryParse(typeId);
  ContraptionType type = CreateBuiltInRegistries.CONTRAPTION_TYPE.get(id);
  return type == null ? null : type.factory.get();
}

Now it's clear. The method explicitly warns about null twice: with an annotation and a comment. However, the caller code doesn't check anything.

The PVS-Studio warning:

V6008 Potential null dereference of 'contraption'. Contraption.java 230

It's easier to break than it seems. The very first line calls nbt.getString("Type"), and if the key doesn't exist, an empty string is returned. This type isn't in the registry either, so the code returns null again.

We can verify this pretty easily by giving ourselves a minecart with a nonexistent contraption type:

/give @p
create:minecart_contraption[create:minecart_contraption_data=
{Type:"create:does_not_exist",InitialOrientation:"north"}]

What's a contraption?
A contraption is a structure that the mod detaches from the world and turns into a single movable object: a platform on a minecart, a piston carrying a load, or a rotating bridge. The blocks inside stop being part of the world and are stored as data belonging to a single entity instead.

The command won't break anything, and the item will go into the inventory without a problem. But once we put the minecart on the rails, MinecartContraptionItem will try to build a contraption from this data, and that's where we'll get a stack trace with NullPointerException. Minecraft will replace the player's contraption with a vanilla minecart.

We can easily add the check:

Contraption contraption = ContraptionType.fromType(type);
if (contraption == null) {
  Create.LOGGER.warn("Unknown contraption type: {}", type);
  return null;
}

But then null will need to be handled in both code snippets that call it. That raises the question of what to do with a minecart whose contents the mod can no longer understand. Should we leave it as an empty minecart, or simply not load the entity at all? I think it's worth asking the mod developers. They clearly know better than anyone else what to do here.

Interruption

The ServerLagger.java(14) file

public void tick() {
  if (!isLagging || tickTime <= 0)
    return;

  try {
    Thread.sleep(tickTime);
  } catch (InterruptedException e) {
    e.printStackTrace();
  }
}

The PVS-Studio warning:

V6103 Ignored InterruptedException could lead to delayed thread shutdown. ServerLagger.java 14

ServerLagger is a helper class for the killtps start <tickTime> debug command that puts the server to sleep for the specified number of milliseconds on every tick, allowing to see how the mod behaves when the TPS drops. It's available only in debug builds and only to operators (that's what server administrators are called), so there's no need to worry. However, the code is still incorrect, and it's worth explaining why.

When the thread is interrupted, sleep immediately throws an InterruptedException and also clears the interrupt flag. In other words, after catch, it seems like nothing's left: no flag, no exception, just a line in System.err. The method returns control without issue, and the server continues running as if it had never been called.

An interrupt is a request for the entire thread to stop, not just the part where you catch it. By interrupting the thread and doing nothing, you take that request and throw it away. The Javadoc explicitly points this out. One line is enough to pass the interrupt:

} catch (InterruptedException e) {
  Thread.currentThread().interrupt();
}

Conclusion

That's all for today. I collected all the bugs both in this article and in pull requests for the project's developers (click, click).

Want to try static analysis too? You can always integrate it into your own project with PVS-Studio. You can download a trial version here. The license is free for open-source projects.

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

Unicorn Developer — Wed, 23 Sep 2026 12:35:34 +0000

We continue the development of our toy programming language. In this episode, our speaker Yuri demonstrates how to implement functions and explains how functions, scopes, and symbol lookup are built in code using C++.

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.

Introducing scopes

Functions introduce multiple scopes and different levels of name visibility. Unlike variables, which previously existed only in the global scope, functions create their own scope. Names declared inside a function are not visible outside it, while names from parent scopes remain accessible. Compound statements can also create nested scopes.

Managing the symbol table

To resolve names, the semantic analyzer uses a symbol table that associates names with their declarators and the scopes where they appear. Two lookup methods are used. An unscoped lookup searches the current scope and then moves upward through parent scopes until it finds the name. A scoped lookup checks only a specified scope. The latter also prevents duplicate names from being declared within the same scope.

Parsing functions

A function consists of the fn keyword, a name, parameters, an optional return type, and a compound statement containing its body. Parameters have a type and a unique name. Functions are parsed in two stages: the declaration is parsed and registered in the symbol table before the body is processed. This allows the function to reference itself recursively.

Handling return types

The semantic analyzer determines a function's return type from its return statements when no type is specified. It also checks that return expressions are compatible with the function's return type and adds implicit casts when necessary. An empty function with no return statements gets the void type. Incompatible return types make the function invalid.

The talk concludes with functions implemented and introduces the evaluator as the next step.

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. Evaluator. We hope to see you there!

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

See ya!

Live talk on how to create your own Go analyzer

Unicorn Developer — Fri, 18 Sep 2026 12:48:45 +0000

Static analyzers are powerful tools, and any Go developer who has worked with go vet knows how useful they can be. What happens when the tools you have at your disposal don't catch the most important issues in your projects, though? You could look for another solution... or you could build your own!

In our upcoming live talk, we'll explore how Go's built-in tools and code-parsing capabilities can help you take the first steps toward creating a static analyzer tailored to your needs.

From Go's built-in tools to your own analyzer

A PVS-Studio Developer Advocate will walk you through the foundations needed to understand before building a Go analyzer. We'll start with Go's built-in tools and code-parsing capabilities, then move on to the basics of static analysis. From there, we'll look at what a semantic model is and how it fits into the analysis process. Another important part of the talk will be building a syntax tree.

The goal of this talk is to bring all the pieces together and show how they can be used to create your own static analyzer. Instead of relying solely on existing tools, you can tailor an analyzer to catch the issues that matter most in your projects.

Join us live

Join us on September 30, 2026, at 1:00 PM UTC+1 for "Go vet can't go: How to create your own Go analyzer?"

PVS-Studio for Go: Quick overview of new diagnostic rules

Unicorn Developer — Thu, 17 Sep 2026 11:41:35 +0000

PVS-Studio 8.0 is here! We added support for Go project analysis and much more. This article discusses some of the new diagnostic rules for Go that we developed for the latest version of our analyzer.

Introduction

PVS-Studio 8.0 officially introduced support for analyzing Go projects, as well as the option to work directly from GoLand and Visual Studio Code when using Go.

The Visual Studio Code plugin also received a major overhaul. It now supports Go project analysis and all the new analyzers introduced in PVS-Studio 8.0. You can learn about other new features in the press release.

The new release also added 40 new diagnostic rules for Go to the analyzer. In this article, we'll take a look at some of the most interesting ones, explore different use cases, and compare them with traditional tools. Enjoy the read!

Classic errors

We'll start with something that isn't specific to the Go language. Instead, let's focus on more universal and familiar territory: the mistakes that anyone can make when coding or communicating, regardless of the language used.

I should mention that our approach to the "typical developer mistakes" is somewhat different. In addition to studying Go projects, developer forums, and other resources, we used our "secret weapon" to develop diagnostic rules that detect common issues.

That's 18 years of experience searching for issues in code :)

Thanks to this experience in developing analyzers for C, C++, C#, and Java, we've built solid expertise in detecting common mistakes that developers can make regardless of the language they use. This enables us to consider more error cases and scenarios when designing a new analyzer.

Mistakes like typos, copy-paste errors, and other patterns inherent to human behavior may seem simple...

Let's look at a few examples.

Accessing by constant index within a loop

The example:

for i := 0; i < n; i++ {
    sum += arr[0]     // <= It should most likely be arr[i]
}

The PVS-Studio warning: V8008. Suspicious access to a collection element by a constant index inside a loop.

This diagnostic rule is interesting because the issue isn't a syntax error, but rather a logical one—a mistake that developers of any skill level can make.

The index is syntactically valid, so the compiler doesn't report the error, but it remains. Situations like "Oops, I forgot to change i to j" or "I forgot that i even existed" are far more common than you might think. At this point, it becomes a pattern rather than an isolated issue.

We cover this because we know firsthand that developers make such mistakes! Each of our "classic" analyzers has equivalent rules (V3102 is for C#, V767 is for C++, and V6016 is for Java) and includes examples of such mistakes found in popular open-source projects. So, these issues shouldn't be underestimated. You can find examples of errors here:

C# examples (.NET 8, Orleans, PascalABC.NET, etc.);
C++ examples (Godot Engine, RT-Thread, etc.);
Java examples (Apache Solr, Bouncy Castle, Apache Dubbo, etc.).

Recurring condition check

The example:

if A == B {
  if A == B {
    ....
  }
}

The PVS-Studio warning: V8020. Recurring check. This condition was already verified on a previous line.

As you can see, I wasn't lying when I said these mistakes look simple... almost too simple.

And that's the scary part! You get this strong feeling, "I'd never, ever make a mistake like that. I'm not that silly." Then a fly buzzes by, a bug slips through, a colleague walks over, and suddenly there's a couple of checks doing the same thing.

Here's a real-world example from the Incus project, which we covered in one of our articles:

err = p.Save(pidPath)
if err != nil {
    err2 := p.Stop()
    if err != nil {        // <= It looks like it should be err2
        return fmt.Errorf("...: %s: %s", err, err2)
    }
    ...
}

The PVS-Studio warning: V8020 Recurring check. The 'err != nil' condition was already verified on line 407 proxy.go 407

The second condition should check err2 instead of err, as err has already been checked and hasn't changed since.

However, there's more to it because err2 appears in the error handling:

return fmt.Errorf("....: %s: %s", err, err2)

At first, you might not see anything unusual about this context. Although, the answer is obvious: if a problem occurs while handling errors, it becomes more difficult to detect and fix them.

Here's one more point worth mentioning. Go's error-handling philosophy follows a simple principle: "an error is a value." The caller must explicitly handle an ordinary value that a function explicitly returns. Such code is common and boilerplate, so it's easy to make mistakes with it!

We designed one of our new diagnostic rules with this particular aspect of Go in mind:

V8023. It is possible that a wrong variable of the 'error' type is checked for 'nil'.

The example:

func processOrder(orderID string) error {
    order, err := fetchOrder(orderID)
    if err != nil {
        return fmt.Errorf("fetch order: %w", err)
    }

    payment, errPay := chargePayment(order)
    if err != nil {          
        return fmt.Errorf("charge payment: %w", err)
    }

    return savePayment(payment)
}

Now, let's return to the topic of common developer mistakes and discuss copy-pasting. You can notice that err is used instead of errPay in the second case. The result of chargePayment is assigned to a different variable, but developers forgot to change the variable name.

It's easy to spot most of the errors in the context of this article. However, during a code review or while writing code, when we're not looking at a single function but rather going through hundreds or thousands of code lines without a break, it's easy to miss such issues.

We discussed this and other issues related to error handling in Go in the "Error handling in Go: Common pitfalls" article.

The parameter is overwritten before it is used

The example:

func Translate(value *T, numericValue int) {
    numericValue = reader.ReadInt32()   // <= the initial parameter value 
                                        //    isn't used anywhere
    ...
}

The PVS-Studio warning: V8038. A parameter is always rewritten in the function body before being used.

This is a rather unfortunate error because the value passed to the function parameter is never read; it's immediately overwritten inside the function body.

Technically, this isn't a compilation error, so everything should work as expected. However, it usually indicates one of two things: either the input value wasn't used, or the variables got mixed up during refactoring.

Basic tools aren't always enough

Having a nice set of tools right out of the box—and, of course, various open-source solutions—is always great, but they might not be enough for more demanding tasks.

Let's take the very first diagnostic rule of our Go analyzer as an example:

V8001. Identical sub-expressions to the left and to the right of the 'foo' operator.

Look at the example:

func rgb1(r float32, g float32, b float32) {
  if r > 1 || g > 1 || r > 1 {
    ....
  }
}

The error lies in the identical sub-expressions within the binary expression. This issue may arise from carelessly copying code. Such errors are common and nothing out of the ordinary; so, go vet can spot them.

However, things aren't always that simple... Let's take a look at this code:

func rgb(r float32, g float32, b float32) {
  if r > 1 || g > 1 || 1 < r {
    ....
  }
}

The only change is that 1 and r have switched places. Here's the catch, though: go vet doesn't issue any warnings, but the problem remains, since the r > 1 sub-expression is equivalent to 1 < r.

Impossible type assertion

Here's another case involving the V8035 diagnostic rule: an impossible type assertion.

Check out this example:

var v interface {
    Read()
    Read2()
    Read3()
    Read4()
    Read5()
}
_ = v.(io.Reader)

The idea is simple: v is declared as an anonymous interface with the Read() method, whose signature doesn't match Read([]byte) (int, error) from io.Reader/io.ReadCloser (in the example, Read() has no arguments).

So, no specific type can implement both the v anonymous interface and io.Reader/io.ReadCloser simultaneously. So, this implementation guarantees that assertion will throw a panic at runtime. The compiler doesn't catch this because it's technically valid Go code, and everything runs smoothly.

Now wait for it... Go vet can detect it! This is a well-known and well-documented issue, so it should come as no surprise.

By the way, PVS-Studio issues the following message for such code:

The PVS-Studio warning: V8035. Type assertion is always false. Check the 'interface{Read(); Read2(); Read3(); Read4(); Read5()}' and 'io.Reader' interfaces, as they contain methods with incompatible signatures.

Here's another example:

var v interface {
    Read()
}

switch v.(type) {
case io.ReadCloser:
    fmt.Println(1)
default:
    fmt.Println(2)
}

The PVS-Studio warning: V8035. Type assertion is always false. Check the 'interface{Read()}' and 'io.ReadCloser' interfaces, as they contain methods with incompatible signatures.

In fact, it's exactly the same impossible assertion. The only difference is that the assignment is now done using case in the switch statement and via v.(type), rather than via v.(io.ReadCloser).

This is where I'm supposed to say that go vet can't detect it... but no! It can, but that's not the point here. A popular open-source analyzer won't detect the issue here, but it will spot it in the first case. This is a false negative that occurs when a warning isn't issued when it should be.

This presents a dilemma: you can either look for a tool that covers all use cases and spend time trying out different options, or you can take a closer look at PVS-Studio. It's designed for in-depth analysis and comes with guaranteed support for many years to come.

If you have any doubts about our claims, feel free to try our tool and draw your own conclusions.

Well, enough with the synthetic code. Will we show some real code, though?

Some real code

Do you remember the very first Go analyzer diagnostic rule I covered at the beginning of this section? Here's a real example of the warning from the Nuclei project:

func NewEntityParser(dir string) (*EntityParser, error) {

  cfg := &packages.Config{
    Mode: packages.NeedName | packages.NeedFiles | packages.NeedImports |
      packages.NeedTypes | packages.NeedSyntax | packages.NeedTypes |
      packages.NeedModule | packages.NeedTypesInfo,
    Tests: false,
    Dir:   dir,
    ParseFile: func(....) (*ast.File, error) {
      return parser.ParseFile(fset, filename, src, parser.ParseComments)
    },
  }
}

The PVS-Studio warning: V8001 There are identical sub-expressions 'packages.NeedTypes' to the left and to the right of the '|' operator. parser.go 33

If we take a closer look, we can see that the packages.NeedTypes flag is pointlessly repeated here. This error may have occurred due to code autocompletion or a typo. Most likely, there should be the packages.NeedTypesSizes flag here:

const (
  ....
  // NeedTypes adds Types, Fset, and IllTyped.
  NeedTypes

  // NeedSyntax adds Syntax and Fset.
  NeedSyntax

  // NeedTypesInfo adds TypesInfo and Fset.
  NeedTypesInfo

  // NeedTypesSizes adds TypesSizes.
  NeedTypesSizes

  ...
)

It might seem like a simple mistake, but the standard go vet won't catch it. Yet the open-source tool I mentioned in the previous case study does find it. So, I'd like to reiterate the issue: go vet sometimes finds problems that other tools don't, and vice versa.

We discussed this and other errors that the standard go vet can't detect in the "Go vet can't go: How PVS-Studio analyzes Go projects" article.

Go-specific issues

Of course, Go has its own pitfalls. Even seasoned Go developers may not be familiar with all of the language's unique features and tricky parts (not to mention those coming from other languages).

For such cases, our comprehensive documentation provides detailed explanations of why this or that error occurred. We also have examples of common mistakes and how to fix them :)

Well, let's look at a couple of diagnostic rules.

recover() inside an anonymous function that isn't wrapped in defer

In Go, recover resumes execution only if called inside a deferred (defer) function.

However, if an anonymous function with recover is called immediately as (func() { ... }()), by the time a potential panic occurs, that call will have long since completed—recover is physically unable to catch it. So, if a panic occurs, the goroutine can't resume execution.

Here's the example:

func foo() {
    func() {
        if r := recover(); r != nil {
            fmt.Println("Recovered", r)
        }
    }()                        // <= recover started and finished immediately
    q, r := bits.Div64(hi, lo, y) // panic, recover won't help here anymore
}

After defining the anonymous function and calling it, the bits.Div64 function is called. This function can trigger a panic if y equals 0. If that panic reaches the top of the stack, the program will crash.

Of course, the documentation explains how to fix this: the anonymous function call needs to be deferred using the defer keyword:

func foo() {
  defer func() {
    if r := recover(); r != nil {
      fmt.Println("Recovered", r)
    }
  }()
  q, r := bits.Div64(hi, lo, y)
}

For more details, refer to the documentation.

They couldn't have made such a mistake, right?

Here's an error so interesting that we wrote an article about it titled "One mistake no one has ever made. Right?"

Since the article describes it pretty thoroughly and includes examples from real projects, I'll just give a brief overview:

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.

Here's an interesting thing: when developing this diagnostic rule, we thought it was "far-fetched" and that "no one would make a mistake like that" because any test would catch it. But the results were fascinating! You can check them out in the article.

Confusing XOR (^) with exponentiation

Here's another interesting Go-specific mistake.

Unlike in Lua, VB.NET, and R, in Go, ^ has nothing to do with exponentiation, which can be a trap for developers switching between languages. This mistake is exciting because, if we recall the problem with universal mistakes from the beginning of the article, it results in an unfortunate combination.

Binary expressions meant for exponentiation become incorrect when a developer chooses ^. This operator actually performs a bitwise exclusive OR.

The example is painfully simple:

x := 2 ^ 16

In reality, the value here is 18 instead of the expected 2 to the power of 16 (65,536). As the documentation suggests, we can use the left bitwise shift operator to get the power of 2.

x := 1 << 16

What's next?

If you're familiar with our work, then you've probably heard that PVS-Studio detects code quality issues and serves as a static application security testing (SAST) solution. This means our analyzer can also spot potential vulnerabilities.

Our new Go analyzer currently includes only a basic set of diagnostic rules that cover common code quality issues. This is just the beginning, though!

Consider this an announcement: we've already started working on SAST coverage for our Go analyzer. Stay tuned to our blog for updates :)

To back that up, let me introduce one of the first diagnostic rules in the code security section.

Trojan Source

Take a look at this code fragment:

isAuthorized := false
/* verify before transfer */ if isAuthorized {
    TransferFunds(account, amount)
/* end verify */ }

What do you think it would look like to the compiler (without all the conventions and low-level details)?

If you think it should look like this:

isAuthorized := false
if isAuthorized {
    TransferFunds(account, amount)

Well, you're almost right...

It looks as though the funds transfer is indeed protected by the isAuthorized check.

However, the issue lurks where we can't see it, because the compiler will interpret this as follows:

isAuthorized := false
TransferFunds(account, amount)

It doesn't look that great anymore, does it? The isAuthorized check never runs because the if statement and {...} ended up inside what the reviewer considered to be "commented-out" text, so the TransferFunds call executes unconditionally.

The code contains special characters that may not be displayed. They can change how the code appears in the development environment. Combinations of such characters can cause a human and a compiler to interpret the code differently.

Here's what the code actually looks like:

isAuthorized := false
/*[RLO] } [LRI] if isAuthorized[PDI] [LRI] verify before transfer */  
    TransferFunds(account, amount)
/* end verify [RLO]{ [LRI]*/

Let's briefly go over what these characters do here:

[LRI] if isAuthorized[PDI]: the fragment between LRI and PDI is isolated and evaluated from left to right as a single block (if isAuthorized).
[LRI] verify before transfer */: to the end of the line; this is also an isolated block (verify before transfer */).
[RLO]: reverses from right to left everything that follows it, and each of the obtained isolated blocks is treated as a single, indivisible character.

The final order is as follows:

'verify before transfer */', 'if isAuthorized', {space}, '{', {space}

And, lo and behold! With a couple of simple gestures, the closing brace visually turns into an opening one.

This is an issue that PVS-Studio will highlight:

The PVS-Studio warning: V5901. OWASP. Code contains invisible characters that may alter its logic. Consider enabling the display of invisible characters in the code editor.

This vulnerability is listed in the OWASP standard, and our other analyzers can detect similar issues:

V5801 — JS\TS;
V5340 — Java;
V5629 — C#;
V1076 — C++.

We've covered this diagnostic rule in more detail in the documentation.

Is this the end? No, it's just the beginning!

The new analyzer for Go projects is here, but this is only the beginning of its story! The 40 diagnostic rules introduced with PVS-Studio 8.0 mark the start of that journey, and your input can make a real difference. If you're a Go developer, we invite you to try our tool for free. If you have ideas for new diagnostic rules or suggestions for improving the existing ones, feel free to reach out to us through the feedback form!

Thanks for reading. Take care of yourself and your code!

What's new in Java 27

Unicorn Developer — Tue, 15 Sep 2026 13:22:03 +0000

Java 27 is here, with four targeted updates and five previews/incubators. We take a closer look at the garbage collector changes, JFR improvements, post-quantum TLS 1.3, and compact object headers (which cut memory usage).

Java platform changes

JEP 534: Compact Object Headers by Default

Link to JEP

In the article about Java 25, we already mentioned compact object headers that we could turn on with a flag. Now there's no need to use the flag.

At that time, we only touched on this topic briefly. Now that it's on by default, we're going to break it down once again, in more depth.

Every object in the heap begins with a header. In the classic layout (in most JVMs), that's two blocks:

lock status, object's age for GC, identity hash;
a compact pointer to the class's metadata.

In total, we get 96 bits (12 bytes) per object, even if it contains very little useful data. Compact object headers compress all of this into 64 bits: the pointer to the class metadata is compressed down to 22 bits.

In theory, saving a few bits is a good thing, though, but what benefits shall we (as JRE users) actually get out of it?

Not long ago, we released a JavaScript/TypeScript analyzer powered by Java 25. We'll use it as a test subject, "set it loose" on the Grafana source code, and run it with and without compact object headers.

Three minutes later, we get this:

Benchmark	With flag	Without flag
Time	81.4 sec	79.4 sec
Committed heap	1 290 240K (~1.23 GB)	1 126 400K (~1.07 GB)
Used heap: output	1 150 092K (~1.1 GB)	773 062K (~738 MB)

Committed heap represents the amount of memory the virtual machine has allocated from the OS and is keeping reserved. Used heap is the memory in use right now—in other words, the number of bytes occupied by live objects that haven't yet been removed by the garbage collector.

As a result, analysis time remained almost unchanged (within margin of error), committed heap decreased by 13%, and used heap shrank by 33% in total! Just one flag reduced our app's memory usage by a full third, wow!

What's the cost of our joy? A 22-bit pointer limits the number of loaded classes to approximately four million. There's no automatic rollback to a non-compact mode—if the limit is exceeded, we'll get an OutOfMemoryError. If your app really hits this limit, you must really love long-lived streams. But if you want to revert to the previous mode, you can do it with another flag:

java -XX:-UseCompactObjectHeaders Application

JEP 523: Make G1 the Default Garbage Collector in All Environments

Link to JEP

Prior to Java 27, the JVM would check the machine at startup, and if it detected fewer than two processors or less than 1,792 MB of memory, it'd just use Serial GC instead of G1. That kind of machine got labeled a "client" machine, and the memory allocator best suited for it was used.

Now, guess what a modest JVM container with a limit of one CPU and 512 MB of memory looks like?

Right. A chunk of containerized Java apps has been running on a client-oriented collector all this time, even though no one consciously made that decision. Worse yet, the same app could get different GCs on the server and in the developer's IDE, which turned reproducing pausing issues into a thrilling quest with a touch of manic laughter.

Java 27 stopped taking the environment into account and now G1 is selected by default:

# Java 25
$ java -XX:ActiveProcessorCount=1 -Xmx256m -Xlog:gc --version
[0.001s][info][gc] Using Serial

# Java 27
$ java -XX:ActiveProcessorCount=1 -Xmx256m -Xlog:gc --version
[0.001s][info][gc] Using G1

The reasoning is simple: improvements to G1's throughput in previous releases have reduced the gap with Serial to almost zero, and G1's pauses are noticeably more pleasant because it can operate concurrently and in parallel. Plus, predictability: the application's behavior no longer depends on how many cores the JVM detected at startup.

If you specifically want to use Serial—it still has the lowest memory footprint and faster startup time—you can still use it: -XX:+UseSerialGC.

Security

JEP 527: Post-Quantum Hybrid Key Exchange for TLS 1.3

Link to JEP

Ever heard of "harvest now, decrypt later"?

This is an amusing category of threats, though: attackers, having access to your traffic but unable to break the TLS connection, simply save the encrypted traffic for later.

Why would they do that, what's the purpose? It's very curious: attackers have a strong faith in global progress and are waiting for a quantum computer capable of breaking elliptic curve key exchange. Medical and banking records, encryption keys, personal data—all of these will still be valuable ten years from now, so the scheme is quite viable.

Following HTTP/3 (see the previous article), support for TLS 1.3 is now available. The session key in TLS 1.3 now gets generated using two algorithms simultaneously: a classic elliptic curve key exchange plus a quantum-resistant algorithm. Such a pairing is called a hybrid group, and the point is that the connection remains secure as long as at least one of the two algorithms is still in service. So this update makes it pointless to wait for a quantum computer to arrive.

For the application, this is free in terms of code: javax.net.ssl automatically sets the hybrid group as the first in the preference list. If the other side supports it, the exchange gets a hybrid approach; if not, everything works as before. There's nothing to touch, unless you've manually set a list of groups via jdk.tls.namedGroups or SSLParameters::setNamedGroups.

But in some cases, we'll still have to pay a little extra: a TLS handshake costs about two KB more. For most applications, this goes unnoticed, but with millions of short connections in the traffic, you'll see it.

An important note: this JEP applies only to key exchange. Certificate signatures are still in the classic format, and this is a deliberate choice: it is impossible to forge a signature retroactively, but it is entirely possible to decrypt recorded traffic.

JFR enhancements

JEP 536: JFR In-Process Data Redaction

Link to JEP

When recording, JFR carefully preserves the entire process environment: environment variables, system properties, and command-line arguments. And that's where, as we all know, database passwords, tokens, and keys to everything tend to live. That's why sending a .jfr file to a colleague—and especially attaching it to a public issue—always came with a slight twinge of anxiety. In most cases, you shouldn't make .jfr files publicly available at all without cleaning them up first.

Starting with Java 27, JFR scrubs sensitive values within the JVM before they're passed to disk. And what does JFR consider to be sensitive data? By default, any environment variable or system property whose name matches one of these patterns gets replaced with [REDACTED]:

*api*key*      *auth*        *client*secret*  *credential*
*jaas*config*  *passphrase*  *passwd*         *password*
*private*key*  *pwd*         *secret*         *token*

Command-line arguments of the form --db-password qwerty123 are handled in the same way.

We can expand the list of properties using the -XX:FlightRecorderOptions:redact-key=+<your-pattern> flag.

It's worth understanding the limits here: the mechanism covers start events (environment variables, system properties, arguments, and JVM information) and is explicitly described as best-effort. It doesn't filter your app's events, exception messages, or child process command lines. In other words, .jfr has become significantly safer now, but not sterile in total. We're still worried, but not as much as before.

In preview

A few more JEPs have been included in the release as previews. We won't cover them for now, we'll wait for their final versions. Here are some links for you to explore on your own:

Conclusion

The full list of JEPs is here.

This was a minor release, and there was nothing here in the way of earth-shattering, 180-degree changes: they've updated the preview and polished up the platform. And that brings useful thing right out of the box for the JVM: objects on the heap are more compact, the garbage collector is the same for both the server and a tiny pod, JFR logs are no longer brimming with secrets, and TLS is preparing for a quantum future.

Essentially, this is preparation for the next LTS. Structured Concurrency is now on its seventh preview, primitives in patterns are in their fifth preview, and the Vector API is waiting for Valhalla. All of this is being finalized so that it can be delivered ready to go with Java 29. Well, for now, though, let's just update and get a more compact heap for free.