Fixed-Width Integer Encoding and Overflow in C++

Hello again. In the previous lesson, you used RAII and std::unique_ptr to make ownership and cleanup reliable across normal returns and exceptions. This lesson turns to a different kind of reliability boundary: the finite set of integer values a machine can represent.

You will learn to read and encode fixed-width bit patterns as unsigned and two’s-complement signed integers, then connect those representations to C++ rules. The crucial distinction is that unsigned overflow has a specified modular result, while signed overflow is undefined behavior—even on hardware where the bits appear to “wrap.”

---

One bit pattern, different numerical meanings

A computer stores bits; a type supplies an interpretation. Consider the 8-bit pattern:

1110 1101

It can mean different values:

• As an unsigned 8-bit integer, it is $237$.
• As a two’s-complement signed 8-bit integer, it is $-19$.
• In hexadecimal, it is ED.

The bits have not changed. Only the interpretation has.

For an $n$-bit unsigned integer with bits $b_{n-1}\dots b_1{b}_0$, the value is:

$$V_{\mathrm{unsigned}}=\sum _{i=0}^{n-1}{b}_i{2}^i$$

Each bit position has a nonnegative weight. For 8 bits, those weights are:

bit:     7    6   5   4   3   2   1   0
weight: 128  64  32  16   8   4   2   1

So:

0010 1101 = 32 + 8 + 4 + 1 = 45
1110 1101 = 128 + 64 + 32 + 8 + 4 + 1 = 237

An unsigned $n$-bit type has exactly $2^n$ possible patterns and values in this range:

$$0\text{ through }{2}^n-1$$

For 8 bits, that is $0$ through $255$.

Watch this short portion of Computer Science: The Magic of Two's Complement Binary Math from C++ Weekly With Jason Turner. It establishes the four-bit version first, which is much easier to reason about than jumping directly to 32-bit machine integers.

Why not use a separate sign bit?

A tempting design is sign-magnitude:

• The highest bit says positive or negative.
• The remaining bits give the magnitude.

For 8 bits, 0000 0000 would mean $+0$, but 1000 0000 would mean $-0$. Two representations for zero waste a pattern and complicate arithmetic.

Modern systems instead use two’s complement for signed integers. In C++20’s integer model, standard signed integer types use two’s-complement representation. This gives one zero and lets the processor use ordinary binary addition for signed and unsigned values alike.

---

Reading two’s-complement values

For an $n$-bit two’s-complement value, the highest bit has a negative weight:

$$V_{\mathrm{signed}}=-b_{n-1}{2}^{n-1}+\sum _{i=0}^{n-2}{b}_i{2}^i$$

For an 8-bit signed value, the leftmost bit weighs $-128$, not $+128$. The range is therefore:

$$-2^{n-1}\text{ through }{2}^{n-1}-1$$

For 8 bits:

$$-128\text{ through }127$$

Here are several useful patterns to memorize:

Bits	Unsigned interpretation	Signed two’s-complement interpretation
0000 0000	0	0
0000 0001	1	1
0111 1111	127	127
1000 0000	128	-128
1111 1111	255	-1
1110 1101	237	-19

For example, decode 1110 1101 as signed:

$$-128+64+32+8+4+1=-19$$

There is also a faster practical method for negative values:

1. Notice that the top bit is 1, so the value is negative.
2. Flip every bit.
3. Add one.
4. Read the resulting positive magnitude, then apply a minus sign.

For 1110 1101:

original:  1110 1101
invert:    0001 0010
add one:   0001 0011

0001 0011 is $19$, so the original pattern represents $-19$.

This is why negation of a two’s-complement bit pattern is often described as “invert the bits and add one.” At a machine level, it is a very convenient identity:

$$-x=\sim x+1$$

There is one asymmetric edge case: the most negative value has no positive counterpart in the same signed type. In 8 bits, $-128$ is representable, but $+128$ is not. That asymmetry is the source of several boundary bugs.

Hexadecimal is useful because one hex digit represents exactly four bits:

1110 = E
1101 = D

Thus 1110 1101 becomes 0xED. When inspecting memory, registers, packet bytes, or debugger output, hex is usually more compact than binary while preserving the bit structure.

---

Fixed width and the hardware’s arithmetic

A fixed-width integer has room for only a fixed number of bit patterns. If an 8-bit addition produces a ninth carry bit, that carry cannot be stored in the 8-bit result.

For example:

  1111 1111   255
+ 0000 0001     1
------------
1 0000 0000

The lower eight bits are 0000 0000. Hardware commonly retains only those bits when operating at that width.

Mathematically, this is arithmetic modulo $2^n$. For an 8-bit unsigned value:

$$255+1\equiv 0(\mathrm{mod}256)$$

Likewise:

$$0-1\equiv 255(\mathrm{mod}256)$$

This is not an accident or an error for unsigned types. It is their specified model.

The same bit-level addition can have a very different signed interpretation. In four bits:

0111 + 0001 = 1000

As unsigned values, this is $7+1=8$, which is representable.

As signed two’s-complement values, it appears to be $7+1=-8$. But the mathematically correct signed result, $8$, is outside the signed four-bit range of $-8$ through $7$. The bit pattern exists, but it does not make the signed operation valid in C++.

That distinction between stored bits, hardware behavior, and language semantics is essential.

---

C++ makes unsigned and signed overflow different contracts

C++ specifies unsigned arithmetic modulo $2^n$, where $n$ is the number of value bits in the unsigned type. For example, if std::uint32_t exists, it has exactly 32 value bits:

#include <cstdint>
#include <iostream>
#include <limits>

int main() {
    std::uint32_t value =
        std::numeric_limits<std::uint32_t>::max();

    std::cout << value << '\n';  // 4294967295

    ++value;

    std::cout << value << '\n';  // 0
}

The increment is defined. Its result is:

$$(2^{32}-1+1)\mathrm{mod}{2}^{32}=0$$

This is called unsigned wraparound. It can be useful when modular arithmetic is genuinely the intended model: bit masks, hashes, some protocol sequence numbers, and low-level binary algorithms all use it deliberately.

Now compare signed arithmetic:

#include <iostream>
#include <limits>

int main() {
    int value = std::numeric_limits<int>::max();

    ++value;  // undefined behavior

    std::cout << value << '\n';
}

The increment asks C++ to represent one more than the largest int. That result does not fit. C++ calls this undefined behavior.

Undefined behavior does not mean “C++ guarantees two’s-complement wraparound.” Your particular CPU may produce the low-order bit pattern corresponding to a negative value, especially in an unoptimized debug build. But once signed overflow occurs, the C++ standard places no requirements on the program’s behavior.

Read the concise reference section below before running the lab. It states the language-level rule directly.

A compiler can exploit this rule. Consider:

bool strictly_increases(int x) {
    return x + 1 > x;
}

For every execution that has defined behavior, x + 1 must be representable. Therefore, it must be greater than x. An optimizing compiler may legally treat this function as always returning true.

The special input INT_MAX does not force the function to return false; evaluating x + 1 for that input is already undefined behavior. This is why checking for signed overflow after performing the overflowing operation is not a valid strategy.

Watch the selected excerpts from Undefined Behavior in C++: What Every Programmer Should Know and Fear by Fedor Pikus at CppCon. The first explains the optimization consequence; the second connects it to UBSan.

---

WSL lab: observe defined wrapping and diagnose signed overflow

Create unsigned_wrap.cpp:

#include <cstdint>
#include <iostream>
#include <limits>

int main() {
    std::uint32_t value =
        std::numeric_limits<std::uint32_t>::max();

    std::cout << "before: " << value << '\n';

    ++value;  // defined: arithmetic modulo 2^32

    std::cout << "after:  " << value << '\n';
}

Compile with warnings and run it:

g++ -std=c++20 -Wall -Wextra -Wpedantic -g -O0 \
    unsigned_wrap.cpp -o unsigned_wrap

./unsigned_wrap

You should see the maximum 32-bit unsigned value followed by 0. This is expected, portable behavior for this type.

Now create signed_overflow.cpp:

#include <iostream>
#include <limits>

int main() {
    int value = std::numeric_limits<int>::max();

    std::cout << "before: " << value << '\n';

    ++value;  // undefined behavior

    std::cout << "after:  " << value << '\n';
}

Compile it with UndefinedBehaviorSanitizer:

g++ -std=c++20 -Wall -Wextra -Wpedantic -g -O1 \
    -fsanitize=undefined -fno-sanitize-recover=undefined \
    signed_overflow.cpp -o signed_overflow

./signed_overflow

UBSan should report a signed integer overflow at the increment. The precise wording varies by compiler version, but it will identify that the maximum int value cannot be incremented representably.

A sanitizer finding is useful evidence, but its absence is not a proof of safety. UBSan instruments executed code paths. If a boundary input is never tested, an overflow in that path remains undiscovered.

A small but important uint8_t caveat

Do not assume every expression involving an 8-bit variable is evaluated in 8 bits:

#include <cstdint>

std::uint8_t a = 250;
std::uint8_t b = 10;

auto sum = a + b;  // typically an int with value 260

C++ applies integral promotions before many arithmetic operations. On your WSL compiler, a and b promote to int, so sum is 260, not 4.

However:

a += b;

stores the result back into an unsigned 8-bit object. The conversion to std::uint8_t is defined modulo $256$, so a becomes 4.

This is a subtle but practical lesson: distinguish the width of the storage object from the type in which an expression is evaluated. For testing actual 32-bit unsigned wraparound, std::uint32_t is clearer than std::uint8_t.

---

Design rules for reliable integer code

The correct choice depends on what the number means, not simply on which type has a convenient range.

When wrapping is intended

Use an unsigned type only when the modular behavior is part of the design. Document the modulus mentally or in code comments. A 32-bit unsigned value naturally lives in the ring of values modulo $2^{32}$.

For example, this can be appropriate when intentionally manipulating bit patterns:

std::uint32_t flags = 0;
flags |= 0b0000'0100;

It can also be appropriate for a bounded sequence number if the protocol explicitly defines how values wrap.

When wrapping is not intended

For quantities such as balances, counts subject to limits, array sizes after arithmetic, timestamps, or user-provided values, handle the range before calculating a result that might overflow.

A safe increment API can make the boundary explicit:

#include <cstdint>
#include <limits>
#include <optional>

std::optional<std::int32_t> increment_if_possible(
    std::int32_t value) {

    if (value == std::numeric_limits<std::int32_t>::max()) {
        return std::nullopt;
    }

    return value + 1;
}

The addition occurs only after the upper-bound case has been excluded.

A common alternative for operations on 32-bit signed values is to calculate in a wider type, validate the result, then narrow only if it fits. That approach is useful only when you can establish that the wider intermediate type itself cannot overflow.

Do not confuse conversions with signed overflow

These cases are different:

std::uint32_t bits = static_cast<std::uint32_t>(-1);

Converting a signed value to an unsigned type is defined modulo the destination’s range. For 32 bits, bits becomes the all-ones pattern.

By contrast:

int x = std::numeric_limits<int>::max();
x + 1;  // signed arithmetic overflow: undefined behavior

The first is a defined conversion. The second is an overflowing signed arithmetic operation.

A concise rule to retain is:

Unsigned integers wrap by specification. Signed integers must stay in range.

---

Takeaways

• An $n$-bit unsigned integer represents values from $0$ to $2^n-1$.
• Two’s-complement signed integers represent values from $-2^{n-1}$ to $2^{n-1}-1$.
• The same bit pattern can represent different values depending on whether it is interpreted as signed or unsigned.
• To negate a two’s-complement bit pattern, invert its bits and add one; the minimum signed value is the important asymmetric edge case.
• Unsigned arithmetic is defined modulo $2^n$, so wraparound is predictable.
• Signed overflow is undefined behavior in C++, even if a particular machine appears to wrap its bits.
• Narrow integer types such as std::uint8_t are often promoted before arithmetic; storage width and expression type are not always the same.
• Use UBSan to expose executed overflow paths, but prevent overflow through range checks and deliberate type choices.

Next, you will connect these abstract bit patterns to real execution by examining a short compiler-generated assembly listing and mapping its instructions back to the C++ operations that produced them.