Data Representation: Integers, Floats, Text

A bit is the atom of computing: a physical quantity (voltage, charge, magnetic polarity) that we interpret as either 0 or 1. Eight bits form a byte — the smallest addressable unit on virtually every modern CPU. A byte can hold 2^8 = 256 distinct patterns.

Numbers in binary follow the same positional logic as decimal, but the base is 2 instead of 10. In decimal, 357 means 3×10² + 5×10¹ + 7×10⁰. In binary, 1011 means 1×2³ + 0×2² + 1×2¹ + 1×2⁰ = 8 + 0 + 2 + 1 = 11.

Hexadecimal (base-16) is the systems programmer's shorthand: one hex digit maps to exactly four bits, so a 32-bit word fits neatly in 8 hex digits. The digits 0–9 plus A–F (or a–f) give sixteen symbols. 0xFF = 1111 1111 = 255.

Convention: in C source code, binary literals use the 0b prefix (GCC extension), octal uses 0, and hex uses 0x. In kernel code you will almost always see hex.

#include <stdio.h>

int main(void) {
    unsigned char b = 0b10110011; /* GCC extension */
    printf("decimal: %u\n", b);  /* 179 */
    printf("hex:     0x%02X\n", b); /* 0xB3 */

    /* Manually compute positional value */
    unsigned val = (1<<7)|(0<<6)|(1<<5)|(1<<4)|
                   (0<<3)|(0<<2)|(1<<1)|(1<<0);
    printf("manual:  %u\n", val);  /* 179 */
    return 0;
}

An unsigned integer of width n represents the values 0 through 2ⁿ−1 by interpreting all n bits as a non-negative positional binary number. The C types uint8_t, uint16_t, uint32_t, uint64_t (from <stdint.h>, or u8/u16/u32/u64 in kernel headers) are unsigned integers of exactly 8, 16, 32, and 64 bits respectively.

Arithmetic wraps modulo 2ⁿ. Adding 255 + 1 in a uint8_t gives 0 — the carry bit that would make it 256 is simply discarded. This is not a bug; the C standard defines unsigned overflow as well-defined wrap-around. The kernel exploits this: (u32)(a - b) < threshold is a common idiom to check whether a is within threshold of b even when a < b (the subtraction wraps around but the comparison still works).

Bit manipulation is at the heart of kernel programming. Setting bit k: x |= (1u << k). Clearing bit k: x &= ~(1u << k). Testing bit k: (x >> k) & 1. Isolating the lowest set bit: x & (-x) (this works because of two's-complement negation, covered next).

The range of common unsigned types:

• u8: 0 – 255
• u16: 0 – 65,535
• u32: 0 – 4,294,967,295 (~4 billion)
• u64: 0 – 18,446,744,073,709,551,615 (~18 × 10¹⁸)

#include <stdint.h>
#include <stdio.h>

int main(void) {
    uint8_t x = 255;
    x++;               /* wraps to 0 -- well-defined for unsigned */
    printf("%u\n", x); /* 0 */

    uint32_t flags = 0;
    flags |=  (1u << 3);  /* set bit 3   -> 0x00000008 */
    flags &= ~(1u << 3);  /* clear bit 3 -> 0x00000000 */

    uint32_t v = 0b10110000u;
    printf("lowest set bit position: %u\n",
           __builtin_ctz(v)); /* 4 -- count trailing zeros */
    return 0;
}

How do you represent negative numbers? There are three historic schemes: sign-magnitude, ones' complement, and two's complement. Modern hardware (x86, ARM, RISC-V) uses two's complement exclusively, and since C23 the standard mandates it too.

The key idea: in an n-bit two's-complement integer, the most-significant bit (MSB) has a place value of −2^(n−1) instead of +2^(n−1). All other bits remain positive.

For an 8-bit signed byte:

• 0111 1111 = +127 (MSB=0, so all-positive contributions)
• 1000 0000 = -128 (MSB=1 contributes −128, rest contribute 0)
• 1111 1111 = -1 (−128 + 64 + 32 + 16 + 8 + 4 + 2 + 1 = −1)

Negation rule: to negate a two's-complement number, flip all bits then add 1. Try it: +5 = 0000 0101. Flip: 1111 1010. Add 1: 1111 1011 = -5. Verify: -128 + 64 + 32 + 16 + 8 + 0 + 2 + 1 = -5. ✓

Why two's complement is beautiful: addition and subtraction use identical hardware circuits for signed and unsigned numbers. The CPU doesn't need separate ALUs. The carry flag handles unsigned overflow; the overflow (V) flag handles signed overflow. This elegance is why the entire industry converged on this encoding.

Signed overflow is undefined behavior in C (unlike unsigned wrap-around). The compiler is allowed to assume it never happens and optimize accordingly. This is a real source of kernel security bugs. The kernel uses check_add_overflow() etc. from <linux/overflow.h> to detect it safely.

Ranges for signed types:

• s8 / int8_t: −128 to +127
• s16 / int16_t: −32,768 to +32,767
• s32 / int32_t: −2,147,483,648 to +2,147,483,647
• s64 / int64_t: −9,223,372,036,854,775,808 to +9,223,372,036,854,775,807

#include <stdint.h>
#include <stdio.h>

int main(void) {
    int8_t a = 127;
    a++; /* UNDEFINED BEHAVIOR for signed -- may not be 128 */
    /* But the kernel avoids this -- let's show why: */

    /* Safe check for signed addition overflow */
    int32_t x = 2000000000, y = 2000000000;
    int32_t result;
    if (__builtin_add_overflow(x, y, &result))
        printf("overflow detected!\n");
    else
        printf("result: %d\n", result);
    /* Output: overflow detected! */

    /* Two's-complement negation by hand */
    uint8_t pos = 5;            /* 0000 0101 */
    uint8_t neg = (~pos) + 1;   /* 1111 1011 */
    printf("neg of 5 as u8: %u  (=%d as s8)\n",
           neg, (int8_t)neg);   /* 251, -5 */
    return 0;
}

Real-valued computation (physics simulations, graphics, signal processing) needs numbers with fractional parts and enormous dynamic range. IEEE-754-2008 is the universal standard defining how floating-point numbers are stored and computed.

A 32-bit float (single precision) is divided into three fields:

  31  30       23  22                0
  S   EEEEEEEE   MMMMMMMMMMMMMMMMMMMMMMM
  ^   8 bits      23 bits
 sign  exponent   mantissa (fraction)

• Sign (1 bit): 0 = positive, 1 = negative.
• Exponent (8 bits): stored with a bias of 127. The actual exponent is e_stored − 127. Range: −126 to +127 (the values 0 and 255 are reserved for special cases).
• Mantissa (23 bits): represents the fractional part of a number in the form 1.fraction × 2^exponent. The leading 1 is implicit (not stored) — this is the hidden bit trick that gives you one free bit of precision.

The value of a normal float is therefore: (−1)^S × 1.M × 2^(E−127)

For double (64-bit): sign=1, exponent=11 bits (bias=1023), mantissa=52 bits. Same structure, more room.

Example: decoding 0x40490FDB (π ≈ 3.14159)

• Sign: 0 (positive)
• Exponent bits: 10000000 = 128, actual = 128 − 127 = 1
• Mantissa bits: 10010000111111011011 + zeros → 1.100 1001 0000 1111 1101 1011
• Value: 1.10010010000111111011011 × 2¹ = 11.0010010...₂ = 3.14159265... ✓

Single precision gives about 7 significant decimal digits; double gives about 15-16.

#include <stdio.h>
#include <stdint.h>
#include <string.h>

void decode_float(float f) {
    uint32_t bits;
    memcpy(&bits, &f, 4); /* safe type-punning via memcpy */

    uint32_t sign     = (bits >> 31) & 0x1;
    uint32_t exponent = (bits >> 23) & 0xFF;
    uint32_t mantissa =  bits        & 0x7FFFFF;

    printf("float %f\n", f);
    printf("  hex:      0x%08X\n", bits);
    printf("  sign:     %u\n", sign);
    printf("  exponent: %u (actual: %d)\n",
           exponent, (int)exponent - 127);
    printf("  mantissa: 0x%06X\n\n", mantissa);
}

int main(void) {
    decode_float(3.14159f);
    decode_float(-0.5f);
    decode_float(1.0f);
    return 0;
}

IEEE-754 reserves certain bit patterns for special mathematical entities. Understanding these is critical for writing robust numerical code and for debugging mysterious floating-point results.

Zeros: Both +0.0 and −0.0 exist (only the sign bit differs). They compare equal (+0.0 == -0.0 is true), but 1.0/+0.0 = +∞ while 1.0/-0.0 = -∞.

Infinities: Exponent field = 11111111 (all ones), mantissa = 0. +∞ arises from overflow or 1.0/0.0; −∞ from the corresponding negative cases. Arithmetic on infinity follows mathematical convention: ∞ + 1 = ∞, ∞ - ∞ = NaN.

NaN (Not a Number): Exponent = all ones, mantissa ≠ 0. Represents undefined results: 0.0/0.0, sqrt(-1.0), ∞ - ∞. NaN is contagious — any arithmetic involving NaN produces NaN. Most critically: NaN is not equal to itself — nan != nan is true. This is the canonical NaN test.

Denormalized (subnormal) numbers: Exponent = 00000000, mantissa ≠ 0. These cover the range between 0 and the smallest normal number by giving up the implicit leading 1, allowing gradual underflow. They are slightly slower on some hardware (software emulation needed on older CPUs) but prevent sudden loss of all precision at the boundary.

Why NaN self-inequality matters in the kernel: The kernel avoids FPU in most contexts, but when it does use floats (e.g., in power-management code, or in bpf programs with float-typed map values), mishandling NaN can silently corrupt comparisons.

Quick reference for float exponent=0xFF:

#include <stdio.h>
#include <math.h>   /* -lm */

int main(void) {
    float inf = 1.0f / 0.0f;
    float nan = 0.0f / 0.0f;

    printf("inf:       %f\n", inf);          /* inf */
    printf("inf+1:     %f\n", inf + 1.0f);   /* inf */
    printf("inf-inf:   %f\n", inf - inf);    /* nan */
    printf("nan==nan:  %d\n", nan == nan);   /* 0 -- NaN != NaN! */
    printf("isnan:     %d\n", isnan(nan));   /* 1 */
    printf("isinf:     %d\n", isinf(inf));   /* 1 */

    /* Denormal: smallest positive float */
    float denorm = 1.4e-45f;
    printf("denormal:  %e\n", denorm);
    printf("normal min:%e\n", 1.175494e-38f);
    return 0;
}

Floating-point is an approximation of the real numbers. Most decimal fractions cannot be represented exactly in binary — just as 1/3 cannot be represented exactly in decimal. The number 0.1 in binary is a repeating fraction: 0.000110011001100...₂. The closest 32-bit float to 0.1 is slightly more than 0.1.

When you write 0.1f + 0.2f in C, the CPU adds two approximate values and then rounds the result. The answer is approximately 0.30000001192 — close to 0.3, but not exactly equal to 0.3f (which is a different approximation). Hence 0.1f + 0.2f == 0.3f is false.

The four IEEE-754 rounding modes:

1. Round to nearest, ties to even (default) — the most commonly used, minimizes statistical bias.
2. Round toward +∞ (ceiling)
3. Round toward −∞ (floor)
4. Round toward zero (truncation)

The C99 <fenv.h> header lets you query/set the current rounding mode.

Machine epsilon (ε): The smallest value such that 1.0 + ε ≠ 1.0. For float, ε ≈ 1.19×10⁻⁷; for double, ε ≈ 2.22×10⁻¹⁶. This bounds the relative error of a single rounding step.

Catastrophic cancellation: When two nearly-equal large numbers are subtracted, most significant bits cancel and you're left with mostly noise bits. Example: (1.000001 - 1.000000) in single precision can lose 6 digits of accuracy.

Practical rules for kernel/systems code:

• Never use == to compare floats; compare with a tolerance: fabsf(a - b) < epsilon.
• Avoid float in the kernel when possible — use fixed-point arithmetic instead.
• When you must use float, consider using double for intermediate calculations.

#include <stdio.h>
#include <math.h>
#include <fenv.h>

int main(void) {
    /* The classic surprise */
    float a = 0.1f, b = 0.2f, c = 0.3f;
    printf("0.1 + 0.2 == 0.3? %d\n", a + b == c); /* 0 */
    printf("0.1 + 0.2 = %.10f\n", a + b);  /* 0.3000000119 */
    printf("0.3       = %.10f\n", c);       /* 0.2999999970 */

    /* Correct comparison */
    float eps = 1e-6f;
    printf("close enough? %d\n", fabsf((a+b) - c) < eps); /* 1 */

    /* Machine epsilon */
    float e = 1.0f;
    while (1.0f + e != 1.0f)
        e /= 2.0f;
    e *= 2.0f;
    printf("float epsilon: %.2e\n", e); /* ~1.19e-07 */
    return 0;
}

Before Unicode, before UTF-8, there was ASCII — the American Standard Code for Information Interchange, standardized in 1963. ASCII maps 128 codepoints (0–127, fitting in 7 bits) to characters: 0–31 are control characters (non-printable: newline=10, tab=9, null=0, backspace=8, escape=27, carriage return=13...), 32–126 are printable characters (space, punctuation, digits 0–9, uppercase A–Z, lowercase a–z), and 127 is DEL.

Key structure that every systems programmer internalizes:

• 'A' = 65 = 0x41. 'Z' = 90 = 0x5A. The alphabetic uppercase letters are contiguous.
• 'a' = 97 = 0x61. 'z' = 122 = 0x7A. Lowercase is contiguous and exactly 32 more than uppercase ('a' - 'A' == 32). This means toggling bit 5 (0x20) flips case.
• '0' = 48 = 0x30. '9' = 57 = 0x39. Digits are contiguous. '5' - '0' == 5 converts a digit character to its integer value.
• '\0' (null, codepoint 0) terminates C strings. This is why C strings cannot contain embedded nulls.

In the kernel, ASCII is everywhere: printk format strings, /proc file contents, device driver error messages, sysfs attributes. The kernel's lib/string.c operates on byte sequences, treating each byte as a character — for purely ASCII text, that's fine. It becomes wrong the moment you introduce non-ASCII characters.

ASCII's fatal limitation: it was designed for English. No accented characters, no Cyrillic, no Chinese, no Arabic. The world needed more.

#include <stdio.h>
#include <ctype.h>

int main(void) {
    /* ASCII structure */
    printf("'A'=%d  'a'=%d  diff=%d\n",
           'A', 'a', 'a'-'A'); /* 65, 97, 32 */
    printf("'0'=%d  '9'=%d\n", '0', '9'); /* 48, 57 */

    /* Bit-5 flip converts case */
    char upper = 'G';
    char lower = upper | 0x20;   /* set bit 5 */
    char back  = lower & ~0x20;  /* clear bit 5 */
    printf("%c -> %c -> %c\n", upper, lower, back); /* G -> g -> G */

    /* Digit to integer */
    char digit = '7';
    int  value = digit - '0';  /* 7 */
    printf("'%c' as int: %d\n", digit, value);

    /* Print the printable ASCII table */
    for (int i = 32; i < 127; i++)
        printf("%3d  %c%s", i, i, (i%8==7)?"\n":"  ");
    return 0;
}

Unicode is a project to assign a unique number — called a codepoint — to every character in every writing system ever used. As of Unicode 15.1 (2023), it defines 149,813 characters across 161 scripts plus a vast collection of symbols and emoji.

A codepoint is written U+XXXX (or U+XXXXX for the supplementary planes) in hex. Examples:

• U+0041 → 'A' (Basic Latin, same as ASCII)
• U+00E9 → 'é' (Latin-1 Supplement)
• U+4E2D → '中' (CJK Unified Ideograph)
• U+1F600 → '😀' (Emoji)

Unicode is organized into 17 planes of 65,536 codepoints each. The Basic Multilingual Plane (BMP, plane 0, U+0000–U+FFFF) contains almost all characters in common use. Planes 1–16 are supplementary planes containing historic scripts, emoji, musical symbols, etc.

An important distinction: Unicode is a character set, not an encoding. It defines what number corresponds to each character, but does not specify how those numbers are stored in memory. That is the job of encodings like UTF-8, UTF-16, and UTF-32.

Why this matters for the kernel: The kernel itself mostly lives in ASCII-land, but user-space filesystems (ext4, btrfs) store filenames as byte sequences and must handle Unicode filenames correctly. The utf8proc and nls (National Language Support) subsystems in the kernel deal with Unicode normalization and case-folding for filenames. When you implement a filesystem, you need to know whether two different byte sequences represent the same Unicode character (normalization equivalence).

/* In C11+, you can write Unicode literals directly */
#include <stdio.h>
#include <locale.h>

int main(void) {
    setlocale(LC_ALL, ""); /* use the system locale */

    /* Unicode escape in string literal */
    printf("%s\n", "élève"); /* élève */
    printf("%s\n", "\U0001F600");       /* 😀 */

    /* Codepoints of 'A' and '中' */
    printf("U+%04X\n", (unsigned)'A');  /* U+0041 */

    /* char32_t holds one codepoint (UTF-32) */
    char32_t cp = U'中';
    printf("U+%04X\n", (unsigned)cp);   /* U+4E2D */
    return 0;
}

UTF-8 is the dominant encoding of the internet, Linux filesystems, and terminal output. It encodes every Unicode codepoint as a sequence of 1 to 4 bytes, with the brilliant property that it is backward-compatible with ASCII: any byte value 0–127 is exactly the corresponding ASCII character (1 byte), and no multi-byte sequence ever contains a byte in the 0–127 range.

The encoding rules by codepoint range:

The leading byte tells you the total sequence length (by counting leading 1-bits). Continuation bytes always start with 10. This means:

1. You can always tell where a character starts, even if you jump into the middle of a string.
2. No valid UTF-8 sequence contains the bytes 0xFE or 0xFF (those are used in UTF-16/UTF-32 BOMs).
3. Searching for ASCII characters (like / in a path) is safe even in UTF-8 strings — a / byte (0x2F) never appears as a continuation byte of a multi-byte sequence.

Example: encoding U+4E2D (中)

• Codepoint: 0x4E2D = 0100 1110 0010 1101
• Falls in U+0800–U+FFFF → 3-byte encoding
• Split bits: xxxx = 0100, xxxxxx = 111000, xxxxxx = 101101
• Wait, let me redo: 4E2D = 0100 1110 0010 1101
• Pattern 1110xxxx 10xxxxxx 10xxxxxx → take 16 bits: 0100 111000 101101
  • 1110_0100 10_111000 10_101101 = 0xE4 0xB8 0xAD

Verify in a shell: printf '%s' '中' | xxd → e4 b8 ad ✓

In the kernel, fs/unicode/ implements UTF-8 for case-folding in ext4. The CONFIG_UNICODE Kconfig option enables it. The kernel is careful to validate UTF-8 byte sequences before processing them, because malformed UTF-8 can be a security vector.

/* UTF-8 decoder in C: illustrates the bit patterns */
#include <stdio.h>
#include <stdint.h>

/* Decode one UTF-8 sequence. Returns codepoint, advances *p. */
uint32_t utf8_decode(const uint8_t **p) {
    uint8_t b = *(*p)++;
    if (b < 0x80) return b;                  /* 1-byte: ASCII */
    if (b < 0xE0) {                          /* 2-byte */
        uint32_t cp = (b & 0x1F) << 6;
        cp |= (*(*p)++ & 0x3F);
        return cp;
    }
    if (b < 0xF0) {                          /* 3-byte */
        uint32_t cp = (b & 0x0F) << 12;
        cp |= (*(*p)++ & 0x3F) << 6;
        cp |= (*(*p)++ & 0x3F);
        return cp;
    }
    /* 4-byte */
    uint32_t cp = (b & 0x07) << 18;
    cp |= (*(*p)++ & 0x3F) << 12;
    cp |= (*(*p)++ & 0x3F) << 6;
    cp |=  *(*p)++ & 0x3F;
    return cp;
}

int main(void) {
    /* UTF-8 bytes for '中' */
    const uint8_t buf[] = {0xE4, 0xB8, 0xAD, 0};
    const uint8_t *p = buf;
    printf("U+%04X\n", utf8_decode(&p)); /* U+4E2D */
    return 0;
}

When a multi-byte value (like a 32-bit integer) is stored in memory — which occupies multiple consecutive addresses — there is a choice: do the most-significant bytes go at the lower addresses, or the least-significant?

• Big-endian (BE): Most-significant byte at the lowest address. The bytes are laid out in memory in the same order you'd write the hex number on paper. Network byte order is big-endian. SPARC, PowerPC in big-endian mode, and many embedded chips are big-endian. Think of it like writing a number left-to-right: 0x12345678 in memory is 12 34 56 78.

• Little-endian (LE): Least-significant byte at the lowest address. x86, x86-64, ARM (in LE mode, the default), and RISC-V are little-endian. 0x12345678 in memory is 78 56 34 12. This feels counter-intuitive but has arithmetic advantages: adding numbers starting from the least-significant byte aligns with carry propagation.

Why it matters in the kernel: The kernel runs on both big-endian and little-endian architectures. Filesystem on-disk formats must be consistent regardless of the host CPU's endianness. The kernel uses __le32 (little-endian 32-bit) and __be32 (big-endian 32-bit) types (from <linux/types.h>) as documentation and to enable the sparse tool to detect endianness bugs. Conversion macros like cpu_to_le32(), le32_to_cpu(), cpu_to_be32(), etc., generate zero instructions on the native-endian architecture and a bswap instruction on the opposite one.

Byte-swap by hand for a 32-bit value v: ((v & 0xFF000000) >> 24) | ((v & 0x00FF0000) >> 8) | ((v & 0x0000FF00) << 8) | ((v & 0x000000FF) << 24)

Or use __builtin_bswap32(v) in GCC/Clang, which compiles to a single bswap instruction on x86.

#include <stdio.h>
#include <stdint.h>
#include <string.h>

static void dump_bytes(const char *label, const void *p, int n) {
    printf("%s: ", label);
    const uint8_t *b = (const uint8_t *)p;
    for (int i = 0; i < n; i++) printf("%02X ", b[i]);
    printf("\n");
}

int main(void) {
    uint32_t v = 0x12345678;
    dump_bytes("0x12345678 in mem", &v, 4);
    /* On x86 (LE): 78 56 34 12 */
    /* On SPARC (BE): 12 34 56 78 */

    /* Detect endianness at runtime */
    uint16_t word = 0x0001;
    uint8_t  byte;
    memcpy(&byte, &word, 1);
    printf("this CPU is %s-endian\n",
           byte ? "little" : "big");

    /* Manual byte-swap (equivalent to cpu_to_be32 on LE) */
    uint32_t be = __builtin_bswap32(v);
    dump_bytes("byte-swapped", &be, 4); /* 12 34 56 78 */
    return 0;
}

In portable C, the types int, long, and pointer have implementation-defined sizes. On a 32-bit x86 Linux, long is 4 bytes; on 64-bit x86-64, it's 8 bytes. This variability is a nightmare for data structures that must match hardware layouts or be portable across architectures.

The kernel solves this with explicit-width types from <linux/types.h>:

• u8, u16, u32, u64 — unsigned exact widths
• s8, s16, s32, s64 — signed exact widths
• __le16, __le32, __le64, __be16, __be32, __be64 — endianness-annotated types for sparse checking

Alignment is the requirement that a value of type T should be stored at a memory address that is a multiple of sizeof(T). Most hardware requires this (or performs better with it). A uint32_t at address 0x3 is misaligned on most architectures and will either cause a bus error (ARM, MIPS) or a slow unaligned access (x86). The kernel is full of __attribute__((packed)) and __attribute__((aligned(N))) annotations to control this precisely.

Why alignment matters for kernel data structures: Network packet headers, filesystem on-disk structures, hardware register maps, and DMA descriptors all have exact byte offsets specified by standards or hardware. Using __packed collapses padding, ensuring the C struct exactly mirrors the wire format. Without it, the compiler might insert invisible padding bytes between fields to satisfy alignment, silently corrupting your data.

A concrete hazard: struct { uint8_t a; uint32_t b; } has a 3-byte hole after a on most platforms due to alignment padding. sizeof this struct is 8, not 5. Always verify with offsetof() and sizeof().

#include <stddef.h>
#include <stdio.h>
#include <stdint.h>

struct padded {
    uint8_t  a;     /* offset 0 */
    /* 3 bytes padding inserted by compiler */
    uint32_t b;     /* offset 4 */
    uint8_t  c;     /* offset 8 */
    /* 3 bytes padding at end */
};                  /* sizeof = 12 */

struct __attribute__((packed)) packed_s {
    uint8_t  a;     /* offset 0 */
    uint32_t b;     /* offset 1 -- unaligned! risky on ARM */
    uint8_t  c;     /* offset 5 */
};                  /* sizeof = 6 */

int main(void) {
    printf("padded:  size=%zu, offsetof(b)=%zu\n",
           sizeof(struct padded),
           offsetof(struct padded, b));     /* 12, 4 */

    printf("packed:  size=%zu, offsetof(b)=%zu\n",
           sizeof(struct packed_s),
           offsetof(struct packed_s, b));   /* 6, 1 */
    return 0;
}

Theory becomes concrete when you can see the raw bytes. Several tools let you inspect memory representations directly.

xxd (hex dump of a file or stdin): xxd file.bin shows bytes in hex with their ASCII representations on the right. xxd -e shows in little-endian groupings, xxd -b shows in binary. This is your first tool for decoding on-disk structures, network packets, and binary files.

printf with %x / %02X / %016llX: In C programs, print raw values in hex. The format %08X zero-pads to 8 digits, making 32-bit values easy to read.

gdb x command: x/16xb ptr shows 16 bytes in hex starting at ptr. x/4xw ptr shows 4 32-bit words. x/s ptr shows a C string. This is invaluable for debugging kernel modules with QEMU/gdb.

/proc/pid/mem and dd: On Linux you can read the raw memory of a running process. dd if=/proc/self/mem bs=1 skip=$(printf '%d' 0x400000) count=16 reads 16 bytes from the text segment at the ELF load address.

od (octal dump): od -t x1z shows hex bytes with printable ASCII; od -t d4 shows signed 32-bit integers. A standard POSIX tool available everywhere.

Practicing with these tools will make every concept in this module viscerally real — you will see the IEEE-754 bits, the UTF-8 continuation bytes, the little-endian byte order, and the padding holes in structs.

# Shell session illustrating these tools

# Write a float to a file, then hexdump it
python3 -c "
import struct
with open('/tmp/test.bin','wb') as f:
    f.write(struct.pack('<f', 3.14159))  # little-endian float
    f.write(struct.pack('<I', 0xDEADBEEF))
    f.write('中'.encode('utf-8'))         # 3 UTF-8 bytes
"
xxd /tmp/test.bin
# Expected output:
# 00000000: db0f 4940 efbe adde e4b8 ad      ..I@.......
#
# db 0f 49 40  = 0x40490fdb in LE = pi as float
# ef be ad de  = 0xDEADBEEF in LE
# e4 b8 ad     = UTF-8 for '中' (U+4E2D)

# Verify pi:
python3 -c "import struct; print(struct.unpack('<f', bytes.fromhex('db0f4940'))[0])"