Introduction

Computers run on electricity — on or off, 1 or 0. Everything else (images, text, video, sound) boils down to patterns of these bits. Understanding how numbers and data get represented in memory matters if you want to write code that doesn’t break in production.

The choices made decades ago still affect how we write software today. Floating-point math that made sense in the 1960s still produces head-scratching results. Representing negative numbers led to several competing schemes, each with their own quirks.

When to Use This Knowledge

Apply your understanding of data representation when:

• Debugging numerical precision issues in financial or scientific calculations
• Writing code that manipulates binary protocols or file formats
• Interpreting crash dumps and core files
• Working with bitwise operations for flags and masks
• Understanding why 0.1 + 0.2 != 0.3 in floating-point
• Ensuring cross-platform compatibility for integer sizes

Skip the deep dive if:

• You’re exclusively using high-level languages with arbitrary precision libraries
• You never touch network protocols, binary files, or hardware registers

Architecture Diagram

The journey of data through a computer’s representation layers:

flowchart LR
    A[User Input: -123.456] --> B[ASCII Characters]
    B --> C[Binary Encoding]
    C --> D[IEEE 754 Single Precision]
    D --> E[Hexadecimal: 0xC2F6E979]
    E --> F[Memory Layout]
    F --> G[Registers]
    G --> H[ALU Operations]

Core Concepts

Binary: The Foundation

Binary is a base-2 number system using only digits 0 and 1. Each position represents a power of 2, reading right to left: 1, 2, 4, 8, 16, 32, 64, 128, 256, and so forth.

The binary number 1101 equals: 1×8 + 1×4 + 0×2 + 1×1 = 13

Computers use binary because physical circuits naturally have two states: electricity flowing (on) or not flowing (off). It’s easier to build reliable hardware that distinguishes between two clear states than between ten different voltage levels.

The choice of binary wasn’t inevitable, but it emerged as the practical winner. Early computer pioneers experimented with ternary (base-3) and decimal circuits, but binary won because it maps cleanly to the on/off nature of transistors. A transistor acts as a switch: apply voltage to the gate, and current flows or doesn’t. This binary behavior persists even as transistors have shrunk to nanometers — they’re still fundamentally switches. Noise margin (the voltage difference between a guaranteed “0” and a guaranteed “1”) is much easier to maintain with only two states. With ten voltage levels representing digits 0-9, any noise or signal degradation risks confusing one level for another, requiring far more precise circuitry.

Each bit position represents an increasing power of 2, and this positional weighting is what makes binary notation powerful. Consider the byte 0b10110101: reading from right to left, we have bits at positions 0 through 7, each contributing 2^position if set. The value is (1×2^7) + (0×2^6) + (1×2^5) + (1×2^4) + (0×2^3) + (1×2^2) + (0×2^1) + (1×2^0) = 128 + 0 + 32 + 16 + 0 + 4 + 0 + 1 = 181. This same positional logic applies whether you’re working with 8-bit, 32-bit, or 64-bit values. The pattern extends naturally: 16-bit values add positions 8-15, 32-bit adds 16-31, and so on. This is why programmers think in powers of 2 — each bit position is exactly one power higher than the last.

The Nyquist-Shannon sampling theorem has direct implications for binary representation in digital signal processing. To accurately capture an analog signal, you must sample at least twice the highest frequency you want to reproduce. A 44.1 kHz CD audio sample rate can therefore capture frequencies up to 22.05 kHz — adequate for human hearing. A 1 MHz ADC sampling a 400 kHz signal needs careful design to avoid aliasing. The binary nature of sample values compounds this: if you’re using 12-bit resolution instead of 16-bit, your quantization noise floor is higher, and the effective dynamic range decreases. Each additional binary bit adds roughly 6 dB of dynamic range, which is why high-fidelity audio and precision instrumentation demand more bits, not just higher sample rates.

Hexadecimal: The Human-Friendly Binary

Hexadecimal (base-16) provides a more compact notation for binary data. Each hex digit represents exactly 4 binary bits, and hex digits 0-9, A-F map to decimal 10-15.

Binary: 1111 0101 1010 0011
Hex:    F    5    A    3

Hex is preferred for:

• Memory addresses (which are often aligned to 4 or 8 bytes)
• Machine code opcodes
• Bit masks and flags
• Color codes in web development (though that uses hex for RGB values)

The hex-to-binary mental conversion is straightforward once you internalize the 4-bit groupings. Each hex digit maps directly to a 4-bit binary nibble: 0=0000, 1=0001, 2=0010, 3=0011, 4=0100, 5=0101, 6=0110, 7=0111, 8=1000, 9=1001, A=1010, B=1011, C=1100, D=1101, E=1110, F=1111. To convert hex to binary, expand each digit; to convert binary to hex, group bits in fours starting from the right. This 4-bit alignment is why hex won out over octal (base-8). A byte has 8 bits, which divides cleanly into two hex digits but awkwardly into three octal digits (you need 10 bits to cleanly represent 3 octal digits). Every programmer who has debugged a memory corruption issue or reverse-engineered a protocol has benefited from this design decision.

The choice of 16 as the base wasn’t arbitrary — it aligns perfectly with byte boundaries. A byte holds 8 bits, which is exactly two hex digits. A 32-bit register is 8 hex digits. A 64-bit value is 16 hex digits. This correspondence makes it easy to mentally partition memory addresses, network packet contents, or file offsets. When you’re staring at a hexdump of a core file, you can instantly see which bytes differ from expected values. When a network packet captures shows 0x80 0x00 0x00 0x00, you recognize 0x80 as the high bit set in the first byte — the kind of pattern recognition that decimal notation simply cannot provide.

Experienced programmers develop an intuition for common hex patterns. 0xFF means all bits set — useful for bitmasks that isolate the lower byte, or for checking if a value is at its maximum. 0x00 is all zeros, the null state. 0x80 is the highest bit set, often used as a sign bit or continuation flag in protocol designs. 0x7F is the highest positive value in a signed 7-bit field. 0x40 is the second-highest bit. These patterns recur constantly in machine code, file formats, and network protocols. When debugging a floating-point exception, seeing 0x7F800000 immediately tells you “positive infinity” if you know IEEE 754 layout. Reading hex dumps fluently is one of those skills that separates systems programmers from those who never look below the abstraction layer.

Signed Integers: Three Competing Visions

Computers need to represent negative numbers. Three schemes exist:

Sign-and-Magnitude — The leftmost bit represents the sign (0 = positive, 1 = negative), and the remaining bits represent the magnitude. In 8 bits, 10000001 would be -1 and 00000001 would be +1. This is intuitive but has two representations of zero (+0 and -0) and makes arithmetic circuits complex.

Two’s Complement — The dominant scheme today. Negative numbers are represented by inverting all bits and adding 1. In 8-bit two’s complement, the range is -128 to +127. This scheme has exactly one zero, and arithmetic circuits can add positive and negative numbers using the same circuitry.

// Two's complement demonstration
#include <stdio.h>
#include <stdint.h>

void print_binary(uint8_t n) {
    for (int i = 7; i >= 0; i--) {
        printf("%d", (n >> i) & 1);
        if (i == 4) printf(" ");  // Separate nibbles
    }
}

int main() {
    uint8_t positive = 42;      // 00101010
    uint8_t negative = -42;     // In two's complement: 11010110

    printf("+42 in binary:  "); print_binary(positive); printf("\n");
    printf("-42 in binary:  "); print_binary(negative); printf("\n");
    printf("+42 + (-42) =   "); print_binary(positive + negative); printf(" (should be 0)\n");

    // Key insight: -42 = ~42 + 1
    printf("~42 + 1 =       "); print_binary((~positive) + 1); printf("\n");

    return 0;
}

Biased Representation — Used for exponents in floating-point numbers. A bias value is subtracted to get the actual exponent. The IEEE 754 single-precision uses a bias of 127 for exponents.

Floating-Point: Approximating the Reals

Real numbers (like pi or the square root of 2) can’t be exactly represented in binary with a finite number of bits. Floating-point provides a practical approximation using scientific notation.

IEEE 754 single-precision (32-bit) format:

• 1 bit: Sign (0 = positive, 1 = negative)
• 8 bits: Exponent (biased by 127)
• 23 bits: Mantissa (fractional part, normalized)

Sign (1) | Exponent (8) | Mantissa (23)
   S     |   EEEEEEEE   |   MMMM...MMM

The value represented is: (-1)^S × 1.M × 2^(E-bias)

Special values exist:

• Zero: all exponent and mantissa bits are 0 (sign bit determines +0 or -0)
• Infinity: all exponent bits are 1, mantissa is 0
• NaN (Not a Number): all exponent bits are 1, mantissa is non-zero
• Denormals: all exponent bits are 0 but mantissa is non-zero — these are “subnormal” numbers with reduced precision

#!/usr/bin/env python3
"""
Exploring IEEE 754 floating-point behavior
"""

import struct
import sys

def float_to_hex(f: float) -> str:
    """Convert float to its hexadecimal representation"""
    return hex(struct.unpack('<I', struct.pack('<f', f))[0])

def hex_to_float(h: str) -> float:
    """Convert hex string to float"""
    return struct.unpack('<f', struct.pack('<I', int(h, 16)))[0]

def analyze_float(f: float):
    """Break down a float into its IEEE 754 components"""
    packed = struct.pack('<f', f)
    bits = struct.unpack('<I', packed)[0]

    sign = (bits >> 31) & 1
    exponent = (bits >> 23) & 0xFF
    mantissa = bits & 0x7FFFFF

    actual_exponent = exponent - 127
    implicit_one = 1.0 + (mantissa / (2**23))

    print(f"Float: {f}")
    print(f"Hex: {float_to_hex(f)}")
    print(f"Sign: {sign}")
    print(f"Exponent: {exponent} (actual: {actual_exponent})")
    print(f"Mantissa: {mantissa:06x}")
    print(f"Value: (-1)^{sign} × {implicit_one:.10f} × 2^{actual_exponent}")
    print()

if __name__ == "__main__":
    # Classic floating-point gotcha
    print("=== Classic Gotcha ===")
    a, b = 0.1, 0.2
    c = 0.3
    print(f"0.1 + 0.2 = {a + b}")
    print(f"0.3 = {c}")
    print(f"(0.1 + 0.2) == 0.3: {a + b == c}")  # False!
    print()

    print("=== Analyzing Special Values ===")
    analyze_float(0.0)
    analyze_float(-0.0)
    analyze_float(float('inf'))
    analyze_float(-float('inf'))
    analyze_float(float('nan'))

    print("=== Powers of 2 ===")
    for exp in range(-5, 5):
        f = 2.0 ** exp
        analyze_float(f)

Character Encodings: Beyond Numbers

Text requires its own encoding scheme. The history is complicated:

ASCII (American Standard Code for Information Interchange) — 7 bits, 128 characters. Uppercase A-Z is 65-90, lowercase a-z is 97-122, digits 0-9 are 48-57. Control characters (0-31) handle things like newline and carriage return.

ISO-8859-1 (Latin-1) — 8 bits, 256 characters. Adds characters needed for Western European languages. First 128 match ASCII.

Unicode — Aims to represent every character in every language. Code points are written as U+XXXX, ranging from U+0000 to U+10FFFF (over 1.1 million possible characters).

UTF-8 — Variable-width encoding for Unicode. ASCII characters (U+0000 to U+007F) use 1 byte. Other characters use 2-4 bytes. UTF-8 is the dominant encoding on the web and in Linux/Unix systems.

Character | Unicode | UTF-8 bytes
----------|---------|-------------
A         | U+0041  | 41
€         | U+20AC  | E2 82 AC
😀        | U+1F600 | F0 9F 98 80

// Demonstrating character encoding handling in C
#include <stdio.h>
#include <uchar.h>
#include <string.h>

// UTF-8 aware string length
size_t utf8_strlen(const char *s) {
    size_t count = 0;
    const unsigned char *p = (const unsigned char *)s;

    while (*p) {
        // Count characters, not bytes
        if ((*p & 0x80) == 0) {
            // 1-byte character (ASCII)
            p += 1;
        } else if ((*p & 0xE0) == 0xC0) {
            // 2-byte character
            p += 2;
        } else if ((*p & 0xF0) == 0xE0) {
            // 3-byte character
            p += 3;
        } else if ((*p & 0xF8) == 0xF0) {
            // 4-byte character
            p += 4;
        }
        count++;
    }
    return count;
}

int main() {
    const char *text = "Hello, world! 😀";
    printf("String: %s\n", text);
    printf("Bytes: %zu\n", strlen(text));
    printf("Characters: %zu\n", utf8_strlen(text));

    return 0;
}

Production Failure Scenarios

Scenario 1: The Integer Overflow in Space

What happened: On June 4, 1996, the Ariane 5 rocket flight 501 exploded 37 seconds after liftoff. The inertial reference system attempted to convert a 64-bit floating-point number to a 16-bit signed integer. The value was larger than 32,767 (the maximum for a 16-bit signed integer), causing an overflow.

Root cause: The Ariane 5 used the same software from Ariane 4, but the horizontal velocity of the larger rocket exceeded the range representable in 16 bits.

Mitigation: Always validate integer conversions. Use language features that trap overflow (like -ftrapv in GCC), or use saturation arithmetic for values that shouldn’t overflow. For critical systems, formal methods can prove overflow absence.

// Safe integer conversion with overflow checking
#include <stdint.h>
#include <stdbool.h>
#include <limits.h>

bool safe_int32_from_int64(int64_t val, int32_t *out) {
    if (val > INT32_MAX) {
        fprintf(stderr, "Overflow: %ld > INT32_MAX\n", val);
        return false;
    }
    if (val < INT32_MIN) {
        fprintf(stderr, "Underflow: %ld < INT32_MIN\n", val);
        return false;
    }
    *out = (int32_t)val;
    return true;
}

Scenario 2: Floating-Point Precision in Financial Calculations

What happened: A penny-counting stock trading system accumulated rounding errors over millions of transactions, eventually causing a $500,000 loss.

Root cause: Using IEEE 754 double precision for currency. While 0.1 can’t be exactly represented in binary, the tiny errors accumulated over millions of operations.

Mitigation: Use integer arithmetic for monetary values (store cents, not dollars), or use decimal floating-point libraries like IEEE 754 decimal128 where appropriate.

The mechanism behind this is subtle but real. In IEEE 754 binary floating-point, the fraction 1/10 (0.1) is a repeating binary fraction: 0.000110011001100110011... (the pattern 0011 repeats forever). When you write 0.1 in code, the stored value is the closest representable double, which is slightly larger or smaller than the true value. Adding 0.1 + 0.2 in floating-point doesn’t give you 0.3 — it gives you the closest representable value to the sum of the closest representable values of 0.1 and 0.2. The error in each operation is small, typically around 10^-16 relative error for double precision. But when you’re executing millions of transactions that each involve multiplying or dividing by these imprecise values, the errors compound. A financial system calculating interest, exchange rates, or position sizing can accumulate enough error to swing a portfolio by hundreds of thousands of dollars before anyone notices.

The classic demonstration is console.log(0.1 + 0.2) in JavaScript, which outputs 0.30000000000000004, or in Python: (0.1 + 0.2) == 0.3 returns False. This isn’t a bug in the language implementation — it’s a fundamental property of binary floating-point trying to approximate a decimal fraction. Each operand is rounded to the nearest representable binary fraction, then the operation is performed, then the result is rounded again. The error manifests in the final comparison. Financial systems that compare floating-point values for equality (rather than using a tolerance like abs(a - b) < 1e-9) will make incorrect decisions. A trading algorithm that exits a position when current_price >= target_price might never exit because both values are slightly off from their intended decimal values, even though mathematically the condition should be true.

Real-world examples extend beyond trading systems. In 2010, a Knight Capital group algorithm malfunction cost them $440 million in 45 minutes because of a floating-point rounding issue in their order routing system. Healthcare systems have had issues with dosage calculations where floating-point errors could produce incorrect medication volumes. Airline reservation systems historically used floating-point for currency, leading to discrepancies that required periodic reconciliation runs. The thread connecting these failures: any system where exact decimal arithmetic matters and that uses binary floating-point is accumulating invisible errors. The alternative is decimal floating-point (IEEE 754 decimal128 stores 34 decimal digits of precision) or integer arithmetic (store all currency values in the smallest unit — cents, pence, yen — as integers). Integer arithmetic for currency is simple, predictable, and as fast or faster than floating-point for addition and subtraction. Multiplication and division require extra care to avoid overflow, but the fix is straightforward: convert to cents, operate, then divide back with rounding when needed.

Scenario 3: The Year 2038 Problem

What happened: 32-bit Unix systems use signed 32-bit integers for time_t (seconds since January 1, 1970). On January 19, 2038, this value overflows to negative, representing dates in 1901.

Root cause: The choice of 32-bit signed integer for time_t made sense in 1971 but will break in 2038.

Mitigation: Migrate to 64-bit systems where time_t is 64 bits. Some systems use --enable-64-bit compilation flags. Some use a dual-date approach where pre-2038 and post-2038 routines coexist.

Trade-off Table

Implementation Snippets

Bit Manipulation for Flags

#!/usr/bin/env python3
"""
Bit manipulation utilities for flags and masks
"""

from typing import Callable

def set_bit(value: int, bit: int) -> int:
    """Set a specific bit to 1"""
    return value | (1 << bit)

def clear_bit(value: int, bit: int) -> int:
    """Set a specific bit to 0"""
    return value & ~(1 << bit)

def toggle_bit(value: int, bit: int) -> int:
    """Toggle a specific bit"""
    return value ^ (1 << bit)

def get_bit(value: int, bit: int) -> int:
    """Get the value of a specific bit (0 or 1)"""
    return (value >> bit) & 1

def is_power_of_two(n: int) -> bool:
    """Check if n is a power of two using bit trick"""
    return n > 0 and (n & (n - 1)) == 0

def count_set_bits(n: int) -> int:
    """Count the number of set bits (population count)"""
    count = 0
    while n:
        n &= n - 1  # Clear lowest set bit
        count += 1
    return count

# Example: File permission flags
READ = 0b100  # 4
WRITE = 0b010  # 2
EXECUTE = 0b001  # 1

def add_permission(perms: int, new_perm: int) -> int:
    """Add a permission using bitwise OR"""
    return perms | new_perm

def remove_permission(perms: int, rem_perm: int) -> int:
    """Remove a permission using bitwise AND with complement"""
    return perms & ~rem_perm

def has_permission(perms: int, check_perm: int) -> bool:
    """Check if a permission is set"""
    return (perms & check_perm) != 0

# Demonstration
perms = READ | WRITE  # 0b110 = 6
print(f"Initial permissions: {perms:#o} (octal), {perms:#06b} (binary)")

perms = add_permission(perms, EXECUTE)
print(f"After adding EXECUTE: {perms:#o}")

perms = remove_permission(perms, WRITE)
print(f"After removing WRITE: {perms:#o}")

print(f"Has READ? {has_permission(perms, READ)}")
print(f"Has WRITE? {has_permission(perms, WRITE)}")

Converting Between Bases

#!/usr/bin/env python3
"""
Number base conversion utilities
"""

def int_to_hex(n: int, width: int = 0) -> str:
    """Convert integer to hexadecimal string with optional zero-padding"""
    hex_chars = "0123456789ABCDEF"
    if n == 0:
        result = "0"
    else:
        result = ""
        while n > 0:
            result = hex_chars[n % 16] + result
            n //= 16
    return "0x" + result.zfill(width) if width > 0 else "0x" + result

def int_to_binary(n: int, width: int = 0) -> str:
    """Convert integer to binary string with optional zero-padding"""
    if n == 0:
        result = "0"
    else:
        result = ""
        while n > 0:
            result = str(n % 2) + result
            n //= 2
    return "0b" + result.zfill(width) if width > 0 else "0b" + result

def hex_to_int(hex_str: str) -> int:
    """Convert hexadecimal string to integer"""
    hex_str = hex_str.removeprefix("0x").removeprefix("0X")
    return int(hex_str, 16)

def binary_to_int(bin_str: str) -> int:
    """Convert binary string to integer"""
    bin_str = bin_str.removeprefix("0b").removeprefix("0B")
    return int(bin_str, 2)

def float_to_ieee754(value: float) -> tuple[int, int, int]:
    """Break down float into IEEE 754 components"""
    import struct

    packed = struct.pack('>f', value)
    bits = int.from_bytes(packed, 'big')

    sign = (bits >> 31) & 1
    exponent = (bits >> 23) & 0xFF
    mantissa = bits & 0x7FFFFF

    return sign, exponent, mantissa

# Demonstration
print("=== Base Conversions ===")
print(f"255 in hex: {int_to_hex(255)}")
print(f"255 in binary: {int_to_binary(255)}")
print(f"0xFF in decimal: {hex_to_int('0xFF')}")
print(f"0b1010 in decimal: {binary_to_int('0b1010')}")

print("\n=== IEEE 754 Analysis ===")
sign, exp, mant = float_to_ieee754(3.14159)
print(f"π (3.14159): sign={sign}, exponent={exp}, mantissa={mant:06x}")
print(f"Hex representation: {int_to_hex(sign << 31 | exp << 23 | mant, 8)}")

Observability Checklist

When debugging data representation issues:

• Integer overflow detection — Enable compiler overflow flags (-ftrapv, -fsanitize=integer)
• Floating-point exception flags — Check FE_DIVBYZERO, FE_INVALID, FE_OVERFLOW after calculations
• NaN propagation — Use isnan() and isinf() to detect special values
• Character encoding validation — Verify strings are valid UTF-8 using iconv or similar
• Endianness checks — Use union or struct tricks to detect little vs big endian
• Precision loss tracking — Log when double is coerced to float

Useful diagnostic commands:

# Check for NaN and infinity in a running process
# Attach with GDB and call: isnan(), isinf()

# Hexdump to see raw memory representation
hexdump -C your_file.bin | head -20

# Check floating-point environment
python3 -c "import sys; print(sys.float_info)"

Common Pitfalls / Anti-Patterns

Security Pitfalls

Integer Overflow to Buffer Overflow — This chains an integer overflow with a buffer overflow. A length field stored as a 16-bit integer accepts a value like 65535 (0xFFFF). When the code allocates length + 1 bytes and copies data, the buffer overflows. The 2001 Code Red worm used exactly this technique against Microsoft IIS to inject malicious HTTP requests. Check that integer conversions don’t truncate, and verify length + offset <= buffer_size before any copy operation.

Format String Vulnerabilities — The printf family interprets the format string, not the arguments. Calling printf(user_input) instead of printf("%s", user_input) means the format string itself gets parsed. An attacker supplying %x%x%x%x reads stack values; %n writes the byte count to a pointer on the stack. The wfut program exploited this in BIND for remote code execution. Never pass a user-supplied string as the format argument.

Endianness and Network Protocols — Network byte order is big-endian (most significant byte first), while Intel and AMD processors are little-endian (least significant byte first). When a multi-byte value crosses this boundary without conversion, the receiver reads garbage. Early NFS implementations on mixed-endian networks corrupted files silently. Sun’s wire format spec required big-endian, but some vendors skipped the byte swap. Use htons()/htonl() when sending and ntohs()/ntohl() when receiving. For 64-bit values, reach for htonll() or roll your own with bit shifting.

Unicode Normalization Attacks — Unicode lets you represent the same character multiple ways. “é” is U+00E9 as a single code point, or U+0065 U+0301 (e plus a combining acute accent). Visually identical, bytes different. Phishing attackers register paypa1.com using the combining accent to fool users. OWASP calls this “mixed-use encoding attacks.” Normalize all input to NFC before validation or storage. In Python: unicodedata.normalize('NFC', user_input). In JavaScript: user_input.normalize('NFC'). Normalize before comparison, not after.

Programming Pitfalls

Pitfall: Assuming int is 32 bits In C, int is implementation-defined. Write int32_t or int64_t when you need specific sizes. Embedded systems might have 16-bit int.

Pitfall: Comparing floats for equality 0.1 + 0.2 == 0.3 is false. Use fabs(a - b) < epsilon for approximate equality, where epsilon is your tolerance (like 1e-9 for double).

Pitfall: Assuming char is signed Whether char is signed or unsigned is implementation-defined. Cast to unsigned char when you need to ensure the range 0-255.

Pitfall: Forgetting byte order in serialization Writing int directly to a file and reading on a different architecture will corrupt data. Use explicit serialization with defined byte order.

Pitfall: Assuming sizeof(char) == 1 Technically sizeof(char) is always 1, but char might be 9, 16, or 32 bits on unusual architectures. For bytes, use uint8_t.

Quick Recap Checklist

• Binary (base-2) uses powers of 2; each bit represents an increasing power of 2
• Hexadecimal (base-16) compactly represents 4 binary bits per hex digit
• Two’s complement is the standard for signed integers; it has one zero and symmetric range
• IEEE 754 floating-point approximates real numbers with sign, exponent, and mantissa
• Special floating-point values: zero, infinity (positive/negative), NaN, denormals
• ASCII defines 128 characters; Unicode extends to millions; UTF-8 is variable-width
• Integer overflow wraps silently in C; use overflow-checking modes or explicit checks
• Floating-point precision errors accumulate; use decimal types for financial calculations
• Always validate integer conversions and array bounds before use
• Bit manipulation is powerful for flags, masks, and optimized code

Interview Questions

int len = (int)large_count;  // -1 due to overflow
char* buf = malloc(len);          // malloc(-1) allocates small buffer
memcpy(buf, data, len);           // Overflow!

Decimal  Binary   Grey Code
0        000     000
1        001     001
2        010     011
3        011     010
4        100     110
5        101     111
6        110     101
7        111     100

cat /sys/class/misc/mem/cdev  # If this exists and shows memory devices

file /bin/ls  # Shows architecture - might hint at endianness

python3 -c "import struct; print('Big' if struct.pack('H', 1) == b'\\x00\\x01' else 'Little')"

getconf LONG_BIT  # Returns 32 or 64 (but doesn't determine endianness)
# Or check via sysctl
sysctl -n hw.byteorder

uint8_t u = 255;  // Binary: 11111111
int8_t s = (int8_t)u;  // s = -1
// But:
printf("%d", s);  // prints -1
// And:
printf("%u", (uint8_t)s);  // prints 255

int8_t x = -1;
int8_t y = 2;
int result = x + y;  // result = 1 (correct)
// But:
uint8_t ux = (uint8_t)x;  // 255
uint8_t uy = (uint8_t)y;  // 2
uint8_t ur = ux + uy;     // ur = 1 (255 + 2 = 257, truncated to uint8_t = 1)

// Safe: Use unsigned for bit operations
uint32_t safe_shift(uint32_t x, int bits) {
    return x << bits;  // Well-defined for unsigned
}
// Check before shift if signed:
int safe_left_shift(int x, int bits) {
if (x > (INT_MAX >> bits)) {
// Overflow would occur
return -1; // Or handle error
}
return x << bits;
}

Further Reading

• IEEE 754 Floating-Point Standard — The official IEEE 754-2019 standard
• What Every Computer Scientist Should Know About Floating-Point — David Goldberg’s seminal paper
• Two’s Complement arithmetic — Cornell lecture notes on two’s complement
• Unicode Consortium — Official Unicode standard and character database
• The Art of Assembly Language — Randall Hyde’s comprehensive x86 assembly text
• Boolean Logic & Gates — The logical foundations behind numeric operations
• Assembly Language Basics — See how data types are consumed by processors

Conclusion

Number systems and data representation form the bedrock of all digital computation. From the binary nature of electronic circuits to the complex IEEE 754 floating-point standard, these representation choices ripple through every layer of the system stack. The decisions made decades ago—two’s complement for signed integers, IEEE 754 for floating-point, UTF-8 for text—continue to shape how we build software today.

Understanding these representations isn’t just academic—it directly impacts how you debug numerical issues, design protocols, and write robust code. The integer overflow that destroyed the Ariane 5 rocket, the floating-point precision that causes unexpected test failures, and the endianness bugs that corrupt network packets—all stem from a deep understanding of how data is represented.

Continue your exploration of low-level concepts by studying boolean logic and gates to understand how these representations are manipulated by hardware, or move on to instruction set architecture to see how these data types are consumed by a processor.