Signed vs Unsigned Integers - Integer Data Types | OneNoughtOne

0/361

Data Structures & AlgorithmsInteger Data Types

Integer Data Types

LevelBeginner

Duration75 mins

TopicInteger Data Types

1 / 5

Signed vs Unsigned Integers

The Fundamental Dichotomy in Integer Representation

When you write int x = -5; in code, have you ever paused to consider how the computer understands that this value is negative? At the hardware level, computers only have two states—on and off, 1 and 0. There's no special "negative bit" or "minus symbol" stored in silicon. So how do we represent negative numbers using only binary?

This seemingly simple question leads to one of the most fundamental concepts in computer science: the distinction between signed and unsigned integers. Understanding this distinction is not merely academic—it directly impacts the correctness, security, and efficiency of the software you write.

What You Will Learn

By the end of this page, you will understand: (1) Why the signed vs unsigned distinction exists, (2) How negative numbers are encoded in binary using two's complement, (3) The range implications of choosing signed vs unsigned types, (4) How to recognize and avoid common bugs related to signedness, and (5) When to choose signed vs unsigned integers in practice.

The Core Problem: Representing Negativity in Binary

Let's start with a fundamental observation: binary numbers, by their natural mathematical definition, can only represent non-negative values. A sequence like 1011 directly maps to the decimal value 11 through positional notation:

$$1 \times 2^3 + 0 \times 2^2 + 1 \times 2^1 + 1 \times 2^0 = 8 + 0 + 2 + 1 = 11$$

Every bit contributes a positive power of 2. There's no inherent way to produce a negative result from this scheme. Yet programming requires negative numbers constantly—financial calculations, temperature readings, coordinate systems, and countless other domains depend on values below zero.

The challenge: Given a fixed number of bits (say, 32 bits), how do we encode both positive and negative values within the same bit space?

Why Fixed-Size Matters

Computers work with fixed-width integer types (8-bit, 16-bit, 32-bit, 64-bit) because hardware is designed with specific register and memory bus widths. A 32-bit processor naturally handles 32-bit values in a single operation. This fixed width creates a finite space that must somehow accommodate both positive and negative numbers.

The fundamental trade-off:

If you have n bits, you can represent exactly $2^n$ distinct values. With 8 bits, that's 256 distinct patterns. The question becomes: how do you allocate these 256 patterns?

Unsigned approach: Use all 256 patterns for non-negative values: 0 through 255
Signed approach: Split the patterns between negative and non-negative values

This is the essence of the signed vs unsigned distinction. It's not about storing different data—it's about interpreting the same bit patterns differently.

Unsigned Integers: The Natural Binary Interpretation

Unsigned integers follow the straightforward positional binary interpretation. Every bit pattern maps directly to its mathematical binary value, and all representable values are non-negative.

8-bit Unsigned Integer Range (Sampling)
Binary Pattern	Decimal Value	Interpretation
00000000	0	Minimum value
00000001	1	—
00101010	42	—
01111111	127	Halfway point
10000000	128	—
11111110	254	—
11111111	255	Maximum value

The range formula for unsigned integers:

For an n-bit unsigned integer:

Minimum value: 0
Maximum value: $2^n - 1$

Bit Width	Range
8 bits	0 to 255
16 bits	0 to 65,535
32 bits	0 to 4,294,967,295 (~4.3 billion)
64 bits	0 to 18,446,744,073,709,551,615 (~18.4 quintillion)

When to use unsigned integers:

Unsigned types are appropriate when values are inherently non-negative and you want to maximize the positive range:

Array indices and sizes — An array cannot have negative length
Counts and quantities — You can't have -5 users
Memory addresses — Addresses are always positive offsets
Bit manipulation — When treating integers as bit patterns rather than numeric values
Cryptographic operations — Where modular arithmetic on full-width values is expected

The Unsigned Subtraction Trap

A classic bug: if length is an unsigned integer with value 0, then length - 1 doesn't produce -1. Instead, it wraps around to the maximum unsigned value (e.g., 4,294,967,295 for 32-bit). This unsigned wraparound is a frequent source of security vulnerabilities in C/C++ codebases.

Signed Integers: Historical Representation Schemes

Before we examine the modern standard, it's instructive to understand the historical approaches to representing signed integers. Each approach has different trade-offs, and understanding why they were abandoned illuminates the elegance of the modern solution.

Historical Signed Integer Representations

•Sign-Magnitude Representation — The most intuitive approach: dedicate one bit (typically the leftmost) as a "sign bit" where 0 = positive and 1 = negative. The remaining bits represent the magnitude. Example: in 8-bit sign-magnitude, 00000101 = +5 and 10000101 = -5.
•One's Complement — To negate a number, flip all bits. In one's complement, +5 = 00000101 and -5 = 11111010. This was used in some early computers.
•Two's Complement — The modern standard. To negate a number, flip all bits and add 1. We'll explore this in detail.

Why sign-magnitude failed:

Two representations of zero: 00000000 (+0) and 10000000 (-0) both represent zero, wasting a bit pattern and complicating equality comparisons.
Complex arithmetic circuits: Adding a positive and negative number requires different logic than adding two positives. The CPU needs to check signs, possibly swap operands, subtract magnitudes, and determine the result sign—significantly more hardware.
Subtraction is not just negation plus addition: The hardware complexity increases substantially.

Why one's complement failed:

Still two zeros: 00000000 (+0) and 11111111 (-0) both represent zero.
End-around carry: Addition sometimes requires an "end-around carry" where the overflow bit must be added back to the result—additional hardware complexity.

Both approaches were actually used in early mainframes. The UNIVAC 1100 series used one's complement, while early IBM systems used sign-magnitude. The industry converged on two's complement because it solves all these problems elegantly.

Historical Context Matters

Don't skip this history as "irrelevant trivia." Understanding why two's complement won helps you understand its properties. The design wasn't arbitrary—it was selected because it simplifies hardware implementation while providing clean mathematical properties.

Two's Complement: The Modern Standard

Two's complement is the universal standard for representing signed integers in modern computers. Nearly every processor—from embedded microcontrollers to supercomputers—uses two's complement for signed integer arithmetic.

The definition:

To find the two's complement representation of a negative number:

Start with the binary representation of the positive magnitude
Invert (flip) all bits
Add 1 to the result

Example: Representing -5 in 8-bit two's complement

Start with +5: 00000101
Invert all bits: 11111010
Add 1: 11111011

Therefore, -5 in 8-bit two's complement is 11111011.

8-bit Two's Complement: Complete Range
Binary Pattern	Signed Value	Unsigned Value
01111111	+127	127
01111110	+126	126
00000010	+2	2
00000001	+1	1
00000000	0	0
11111111	-1	255
11111110	-2	254
10000001	-127	129
10000000	-128	128

Key observations:

The sign bit: The most significant bit (MSB) indicates the sign: 0 for non-negative, 1 for negative. But unlike sign-magnitude, this bit also contributes to the numeric value.
Only one zero: The pattern 00000000 uniquely represents zero. There's no wasted "negative zero."
Asymmetric range: The range is -128 to +127 for 8 bits, not -127 to +127. There's one more negative value than positive values.
Wraparound behavior: If you increment 01111111 (+127), you get 10000000 (-128). The number "wraps around" from the maximum positive to the minimum negative.

Why Two's Complement Works

The magic of two's complement: addition works the same regardless of sign. The CPU doesn't need to know whether operands are signed or unsigned—it just adds bit patterns. The interpretation of the result (signed vs unsigned) is up to the programmer/compiler, but the hardware operation is identical.

twos_complement_demo.py
Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
# Demonstrating two's complement properties
# In Python, we can simulate 8-bit two's complement
 
def to_twos_complement(value: int, bits: int = 8) -> str:
    """Convert a signed integer to its two's complement binary representation."""
    if value >= 0:
        return format(value, f'0{bits}b')
    else:
        # Two's complement: 2^bits + value (which handles negative values)
        return format((1 << bits) + value, f'0{bits}b')
 
def from_twos_complement(binary: str) -> int:
    """Convert a two's complement binary string to signed integer."""
    bits = len(binary)
    value = int(binary, 2)
    # If MSB is 1, it's negative
    if binary[0] == '1':
        value -= (1 << bits)
    return value
 
# Examples
print("Positive 5:", to_twos_complement(5))      # 00000101
print("Negative 5:", to_twos_complement(-5))     # 11111011
print("Negative 1:", to_twos_complement(-1))     # 11111111
print("Negative 128:", to_twos_complement(-128)) # 10000000
 
# Verify addition works naturally
# 5 + (-3) should equal 2
five = 0b00000101      # 5
neg_three = 0b11111101 # -3 in two's complement
result = (five + neg_three) & 0xFF  # Mask to 8 bits
print(f"5 + (-3) = {from_twos_complement(format(result, '08b'))}")  # 2

The Mathematical Elegance of Two's Complement

Two's complement isn't just a clever encoding trick—it has deep mathematical properties that make it ideal for hardware implementation.

Interpretation formula:

For an n-bit two's complement number with bits $b_{n-1}b_{n-2}...b_1b_0$:

$$\text{value} = -b_{n-1} \times 2^{n-1} + \sum_{i=0}^{n-2} b_i \times 2^i$$

The most significant bit contributes negative $2^{n-1}$ instead of positive. This single change transforms unsigned into signed interpretation.

Example: Interpreting 11111011 (8-bit)

$$= -1 \times 2^7 + 1 \times 2^6 + 1 \times 2^5 + 1 \times 2^4 + 1 \times 2^3 + 0 \times 2^2 + 1 \times 2^1 + 1 \times 2^0$$ $$= -128 + 64 + 32 + 16 + 8 + 0 + 2 + 1$$ $$= -128 + 123 = -5$$

The Modular Arithmetic Perspective

Another way to understand two's complement: it treats integers modulo 2^n. In this view, -1 and 255 are the same number modulo 256. The "negative" numbers are just the upper half of the modular number circle, reinterpreted with a bias. This perspective is crucial for understanding overflow behavior.

Why the same hardware works for both signed and unsigned addition:

Consider adding two 8-bit numbers. The CPU performs binary addition with carry propagation:

  00000101  (5)
+ 11111011  (-5 signed, or 251 unsigned)
─────────────
  00000000  (0 signed, or 0 unsigned modulo 256)

The hardware doesn't "know" if these are signed or unsigned—it just adds bits. The result is correct for both interpretations:

Signed: 5 + (-5) = 0 ✓
Unsigned: (5 + 251) mod 256 = 256 mod 256 = 0 ✓

This unification of addition logic is why two's complement won. It halves the complexity of arithmetic circuits.

Properties of Two's Complement

•Unique zero representation — Only 000...0 represents zero, no wasted patterns
•Same addition circuit — Hardware for signed and unsigned addition is identical
•Same subtraction circuit — Subtraction is just addition with negated operand
•Simple negation — Flip bits and add 1 (or equivalently, invert and add 1)
•Natural wraparound — Overflow behavior is consistent and predictable
•Sign extension works — To widen a signed value, replicate the sign bit

Range Comparison: Signed vs Unsigned

The choice between signed and unsigned affects the range of representable values. Both use the same number of bits, but they interpret those bits differently.

Signed vs Unsigned Ranges by Bit Width
Bit Width	Unsigned Range	Signed Range
8 bits	0 to 255	-128 to 127
16 bits	0 to 65,535	-32,768 to 32,767
32 bits	0 to ~4.3 billion	~-2.1 billion to ~2.1 billion
64 bits	0 to ~18.4 quintillion	~-9.2 quintillion to ~9.2 quintillion

General formulas:

For n bits:

Type	Minimum	Maximum
Unsigned	0	$2^n - 1$
Signed	$-2^{n-1}$	$2^{n-1} - 1$

The asymmetry in signed ranges:

Notice that signed ranges have one more negative value than positive. For 8-bit signed: -128 to +127 (not -127 to +127). This is because zero takes one of the "non-negative" patterns, leaving one extra pattern for negatives.

This asymmetry matters: you cannot negate the minimum signed value within the same type. In 8-bit signed, -(-128) cannot be represented as +128 because +128 exceeds the maximum (+127). In most systems, -(-128) = -128 due to overflow—a subtle source of bugs.

The Negation Overflow Trap

In two's complement: INT_MIN == -INT_MIN due to overflow. This violates the mathematical expectation that negating a negative number yields a positive number. This edge case causes bugs in code that assumes abs(x) is always positive—for INT_MIN, it remains negative!

negation_trap.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
#include <stdio.h>
#include <limits.h>
#include <stdlib.h>
 
int main() {
    int x = INT_MIN;  // Minimum 32-bit signed integer: -2,147,483,648
    
    printf("x = %d
", x);
    printf("-x = %d
", -x);  // Still -2,147,483,648 due to overflow!
    printf("abs(x) = %d
", abs(x));  // Also still negative!
    
    // This code has undefined behavior in C, but most systems exhibit this
    // The "correct" result (+2,147,483,648) cannot fit in 32-bit signed int
    
    // If you need absolute value that handles INT_MIN:
    long long safe_abs = (x == INT_MIN) ? -(long long)x : (x < 0 ? -x : x);
    printf("safe absolute value: %lld
", safe_abs);  // 2,147,483,648
    
    return 0;
}

Practical Implications in Real Code

The signed/unsigned distinction affects how operations behave, often in subtle ways that cause bugs.

Common Signed/Unsigned Bugs

•Comparison bugs: Comparing signed and unsigned values promotes signed to unsigned, producing unexpected results with negative values
•Loop underflow: for (unsigned i = n-1; i >= 0; i--) is an infinite loop because unsigned values are always ≥ 0
•Subtraction underflow: unsigned size = 0; size - 1 produces maximum unsigned value, not -1
•Array indexing: Using signed results as array indices without checking negativity

Best Practices

•Prefer signed for arithmetic: Most general calculations benefit from signed types to handle intermediate negative values
•Use unsigned for bit manipulation: When treating integers as bit patterns, unsigned provides cleaner semantics
•Be explicit in comparisons: Cast explicitly when comparing signed and unsigned to document intent
•Avoid mixing types: Keep operations homogeneous to avoid implicit conversions

signed_unsigned_bugs.cpp
C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
#include <iostream>
#include <vector>
 
int main() {
    // BUG 1: Signed/unsigned comparison
    int x = -1;
    unsigned int y = 1;
    
    if (x < y) {
        std::cout << "-1 < 1
";  // This WON'T print!
    } else {
        std::cout << "-1 >= 1 (unexpected!)
";  // This prints!
    }
    // Why? -1 is promoted to unsigned, becoming 4,294,967,295
 
    // FIX: Explicit casting with awareness
    if (x < static_cast<int>(y)) {
        std::cout << "-1 < 1 (with explicit cast)
";  // Correct
    }
 
    // BUG 2: Infinite loop with unsigned counter
    std::vector<int> vec = {1, 2, 3, 4, 5};
    // for (unsigned i = vec.size() - 1; i >= 0; i--) {  // INFINITE LOOP!
    //     std::cout << vec[i] << " ";
    // }
    
    // FIX: Use signed type or alternative iteration
    for (int i = static_cast<int>(vec.size()) - 1; i >= 0; i--) {
        std::cout << vec[i] << " ";  // Correct: 5 4 3 2 1
    }
    std::cout << "
";
 
    // BUG 3: Underflow in size calculation
    unsigned size = 0;
    unsigned prev = size - 1;  // Now 4,294,967,295, not -1!
    std::cout << "size - 1 = " << prev << "
";  // Unexpectedly huge!
 
    return 0;
}

When to Choose Signed vs Unsigned

The choice between signed and unsigned is not automatic. Different contexts have different correct choices.

Decision Guide: Signed vs Unsigned
Scenario	Recommended Type	Rationale
General arithmetic	Signed	Handles intermediate negative results naturally
Loop counters	Signed (usually)	Prevents underflow bugs in decrementing loops
Array/container sizes	Unsigned (size_t)	Convention; sizes are inherently non-negative
Bit manipulation	Unsigned	Bit shifts and masks have cleaner semantics
Cryptography	Unsigned	Operations should wrap predictably; no undefined behavior
Hardware registers	Unsigned	Matches hardware's view of bit patterns
Database IDs	Unsigned*	Typically positive; larger range may be beneficial
Coordinates (x, y)	Signed	Negative coordinates are meaningful
Temperature values	Signed	Temperatures can be negative
File offsets	Signed (off_t)	Allows negative seeks relative to current position

Language Conventions Vary

Different languages have different conventions. C++ uses size_t (unsigned) for container sizes, while Java uses int (signed) for array lengths. Rust distinguishes carefully with usize and isize. Understanding your language's conventions prevents friction with standard libraries.

The C++ Core Guidelines perspective:

The C++ Core Guidelines (maintained by Bjarne Stroustrup and Herb Sutter) recommend:

"Prefer int for most integers. Use unsigned only for bit manipulation and when you need modular arithmetic."

This might seem counterintuitive—shouldn't we use unsigned for sizes and counts that "can't be negative"? The argument against is that the bugs from signed/unsigned mixing, comparisons, and underflow often outweigh the benefit of the slightly larger positive range.

The counter-argument:

Others argue that type systems should encode semantic constraints. If a value cannot be negative, declaring it unsigned provides:

Self-documentation of intent
Compiler warnings if negative values are assigned
Compatibility with APIs that expect unsigned types

The debate continues, but being aware of it helps you make informed decisions.

Summary: Signed vs Unsigned Integers

We've covered substantial ground on one of the most fundamental concepts in computer representation of numbers. Let's consolidate:

Key Takeaways

•Binary naturally represents non-negative values — Special encoding is required for negative numbers
•Two's complement is the universal standard — It enables signed and unsigned to share the same addition hardware
•The MSB acts as a sign indicator — But also contributes a negative weight to the value
•Ranges differ by interpretation — Same bits, different ranges: 0 to 255 or -128 to 127 for 8 bits
•Mixing signed and unsigned causes bugs — Implicit conversions often produce surprising results
•Choose types thoughtfully — Consider the domain: arithmetic favors signed; bit manipulation favors unsigned
•Negation of minimum value overflows — -INT_MIN == INT_MIN is a critical edge case

What's next:

With the signed/unsigned distinction understood, we'll explore the ranges of integers in more depth—examining exactly how overflow occurs and what happens when calculations exceed representable bounds. This is where bugs silently creep into production systems.

Page Complete

You now understand the fundamental distinction between signed and unsigned integers. This knowledge forms the foundation for understanding integer overflow, fixed-size storage, and the cost model of integer operations—topics we'll explore in subsequent pages.