Pointer Arithmetic — One-Past-the-End Bug in Trading System

Most C bugs that end careers — buffer overflows, segfaults, corrupted data — trace back to one misunderstood concept: pointer arithmetic. It's not obscure wizardry reserved for OS kernels and embedded systems. It's the engine under every array you've ever used in C, every string you've ever printed, every memcpy that ever moved bytes across memory. If you've ever wondered why arrays and pointers feel interchangeable in C, pointer arithmetic is the answer.

The problem pointer arithmetic solves is elegant: how do you navigate raw memory without knowing the exact address of every element ahead of time? Arrays give you contiguous memory, but they're just a starting address. Pointer arithmetic lets you move through that memory systematically, letting the compiler handle the messy byte-offset calculations based on the data type's size. Without it, you'd be manually computing byte offsets for every element access — error-prone and unreadable.

By the end of this article you'll understand exactly why ptr + 1 doesn't mean 'add 1 byte', how to traverse arrays and strings without index variables, what makes pointer subtraction meaningful, and which patterns experienced C developers actually reach for in production code. You'll also know the two arithmetic operations that look valid but silently corrupt memory — and how to spot them before they bite you.

Pointer Arithmetic — The Address Math That Breaks Trading Systems

Pointer arithmetic is the operation of incrementing or decrementing a memory address by a multiple of the type's size. In C, ptr++ moves to the next element of the array, not the next byte. The compiler scales the offset by sizeof(T). This is the core mechanic: you're doing integer math on addresses, but the unit is the object size, not bytes. The result is a new pointer that either points to a valid element or one past the end of the array. That 'one past the end' address is legal to compute and compare, but dereferencing it is undefined behavior — and that's where production systems die. In practice, pointer arithmetic gives O(1) traversal of contiguous memory and is the foundation of array indexing (a[i] is syntactic sugar for *(a + i)). It's the only way to implement custom allocators, ring buffers, or zero-copy parsers. Trading systems rely on it for low-latency order book processing: iterating over a fixed-size array of price levels without bounds checks. The trade-off is that the compiler trusts you. One off-by-one error and you corrupt adjacent memory — no warning, no exception, just silent data corruption that surfaces hours later as a wrong trade.

Why the Compiler Scales Pointer Steps by the Type Size

Here's the core insight that unlocks everything: when you write ptr + 1, C doesn't add the integer 1 to the address. It adds 1 sizeof(ptr). That scaling is automatic, silent, and non-negotiable.

Why does this exist? Because memory is byte-addressable, but your data isn't byte-sized. An int on most modern systems occupies 4 bytes. If you have an array of ints starting at address 1000, the second element is at address 1004, the third at 1008. Writing ptr + 2 to mean 'skip 8 bytes' would force every programmer to manually multiply by sizeof(int) everywhere — a nightmare that would produce subtly broken code whenever you changed the data type.

C's designers baked the scaling in so that ptr + n always means 'the address of the nth element after ptr', regardless of whether ptr points to a char, an int, a double, or a 200-byte struct. This is also why ptr++ on a double* moves 8 bytes forward, not 1.

This design decision is what makes array[i] syntactic sugar. The compiler literally rewrites it as *(array + i) — pointer arithmetic followed by a dereference. They are exactly the same operation.

#include <stdio.h>

int main(void) {
    int   scores[5]  = {10, 20, 30, 40, 50};
    char  letters[5] = {'A', 'B', 'C', 'D', 'E'};
    double temps[5]  = {36.6, 37.1, 38.0, 36.9, 37.5};

    int    *score_ptr  = scores;   /* points to scores[0]  */
    char   *letter_ptr = letters;  /* points to letters[0] */
    double *temp_ptr   = temps;    /* points to temps[0]   */

    /* Adding 1 to each pointer — watch how far each jumps */
    printf("=== Type sizes on this machine ===\n");
    printf("sizeof(int)    = %zu bytes\n", sizeof(int));
    printf("sizeof(char)   = %zu bytes\n", sizeof(char));
    printf("sizeof(double) = %zu bytes\n", sizeof(double));

    printf("\n=== Address jump when pointer is incremented by 1 ===\n");
    printf("score_ptr  before: %p\n", (void *)score_ptr);
    printf("score_ptr  after:  %p  (jumped %zu bytes)\n",
           (void *)(score_ptr + 1), sizeof(int));

    printf("letter_ptr before: %p\n", (void *)letter_ptr);
    printf("letter_ptr after:  %p  (jumped %zu bytes)\n",
           (void *)(letter_ptr + 1), sizeof(char));

    printf("temp_ptr   before: %p\n", (void *)temp_ptr);
    printf("temp_ptr   after:  %p  (jumped %zu bytes)\n",
           (void *)(temp_ptr + 1), sizeof(double));

    /* Prove array[i] == *(array + i) */
    printf("\n=== array[2] vs *(array + 2) ===\n");
    printf("scores[2]        = %d\n", scores[2]);          /* subscript form   */
    printf("*(scores + 2)    = %d\n", *(scores + 2));      /* pointer form     */
    printf("*(score_ptr + 2) = %d\n", *(score_ptr + 2));   /* via pointer var  */

    return 0;
}

Traversing Arrays and Strings the Way the Standard Library Does It

Now that scaling makes sense, let's look at why experienced C programmers sometimes prefer pointer traversal over index-based loops — and when it actually matters.

The standard library functions like strlen, strcpy, and memcpy are all implemented internally using pointer arithmetic. There's no index counter ticking up — there's a pointer walking forward until a condition is met. This pattern is worth knowing not because it's faster on modern CPUs (it often isn't; compilers are clever), but because it teaches you to think in terms of memory, not arrays.

Pointer traversal also shines when you're working with a section of an array — a slice. Instead of passing both an array and an index, you pass a pointer to where you want to start. The function doesn't need to know the original array at all. This is exactly how C string functions handle substrings: strstr returns a pointer into the original string, not a copy.

The key habit: always keep a sentinel — either a count of elements or a terminator value like '\0' — so your pointer knows when to stop.

#include <stdio.h>

/* Count characters in a string — reimplementing strlen with visible pointer steps */
size_t count_chars(const char *text) {
    const char *cursor = text;   /* cursor walks forward; text stays at the start */
    while (*cursor != '\0') {    /* dereference: read the byte cursor is pointing at */
        cursor++;                /* move cursor one char (1 byte) forward           */
    }
    /* Subtracting two pointers gives element count between them, not byte count */
    return (size_t)(cursor - text);
}

/* Sum a slice of an integer array — no index needed, just start + end pointers */
int sum_range(const int *start, const int *end) {
    int total = 0;
    /* 'end' is one-past-the-last valid element — a standard C idiom */
    for (const int *ptr = start; ptr < end; ptr++) {
        total += *ptr;           /* dereference ptr to read the current element */
    }
    return total;
}

/* Find the first negative number in an array; return pointer to it or NULL */
int *find_first_negative(int *data, size_t count) {
    int *ptr = data;
    int *sentinel = data + count;   /* one past the end — do NOT dereference this */
    while (ptr < sentinel) {
        if (*ptr < 0) return ptr;   /* return the actual address inside the array */
        ptr++;
    }
    return NULL;   /* no negative found */
}

int main(void) {
    /* --- String traversal --- */
    const char *message = "TheCodeForge";
    printf("String: \"%s\"\n", message);
    printf("Length via count_chars: %zu\n", count_chars(message));

    /* --- Slice summing --- */
    int readings[8] = {12, 7, 34, 5, 89, 23, 61, 4};
    /* Sum only elements at index 2, 3, 4 (readings[2] through readings[4]) */
    int slice_sum = sum_range(readings + 2, readings + 5);
    printf("\nReadings array: {12, 7, 34, 5, 89, 23, 61, 4}\n");
    printf("Sum of slice [2..4]: %d  (expected: 34+5+89 = 128)\n", slice_sum);

    /* --- Finding negative values --- */
    int temperatures[6] = {22, 18, -3, 25, -1, 30};
    int *first_negative = find_first_negative(temperatures, 6);

    if (first_negative != NULL) {
        /* Pointer subtraction tells us which index it landed on */
        ptrdiff_t index = first_negative - temperatures;
        printf("\nFirst negative: %d at index %td\n", *first_negative, index);
    }

    return 0;
}

Legal vs. Illegal Pointer Arithmetic — The Rules That Prevent Chaos

Not all pointer arithmetic is created equal. C's standard is precise about what's defined behaviour and what silently explodes.

Legal operations: You can add or subtract an integer to/from a pointer. You can subtract two pointers that point into the same array (including the one-past-the-end position). You can compare two pointers from the same array with <, >, <=, >=. That's it.

Illegal operations: Adding two pointers together is a compile error — it has no geometric meaning. Subtracting pointers from different arrays is undefined behaviour — the result might 'work' on your machine today and crash on the build server tomorrow. Dereferencing the one-past-the-end pointer is undefined behaviour, even though computing its address is fine.

The 'one past the end' rule is subtle but critical. C explicitly allows you to form the address array + N (where N is the array length) as a sentinel for loops. This is valid address arithmetic. What's undefined is actually reading or writing through that address — *(array + N) — because that memory isn't yours.

Pointer comparison with == and != is safe between any two pointers, even from different objects, but < and > between pointers from different objects is undefined. This matters when you're implementing a memory allocator or anything that reasons about relative positions.

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

int main(void) {
    int buffer[5] = {100, 200, 300, 400, 500};
    int *start = buffer;          /* points to buffer[0] */
    int *end   = buffer + 5;      /* one-past-end: valid ADDRESS, never dereference */

    /* === LEGAL: integer + pointer === */
    int *third_element = start + 2;       /* buffer[2], address is buffer_base + 8  */
    printf("Legal: start + 2 = %d\n", *third_element);

    /* === LEGAL: pointer - pointer (same array) === */
    ptrdiff_t distance = end - start;     /* gives 5 — element count, not byte count */
    printf("Legal: end - start = %td elements\n", distance);

    /* === LEGAL: pointer comparison within same array === */
    int *cursor = start;
    int count   = 0;
    while (cursor < end) {   /* cursor < end is legal — both point into buffer */
        count++;
        cursor++;
    }
    printf("Legal: counted %d elements via pointer comparison\n", count);

    /* === LEGAL: one-past-end address computation (no dereference) === */
    printf("Legal: end address computed = %p (not dereferenced)\n", (void *)end);

    /* === ILLEGAL (commented out to keep this code safe to run) ===

    // 1. Adding two pointers — compile error:
    //    int *bad = start + end;   // error: invalid operands to binary +

    // 2. Subtracting pointers from DIFFERENT arrays — undefined behaviour:
    //    int other[5] = {1,2,3,4,5};
    //    ptrdiff_t garbage = buffer - other;  // UB: might crash, might return wrong value

    // 3. Dereferencing one-past-end — undefined behaviour:
    //    int forbidden = *end;   // UB: reading memory that isn't yours

    // 4. Pointer arithmetic past the bounds — undefined behaviour:
    //    int *too_far = start + 10;  // UB even before dereferencing on some platforms
    */

    printf("\nAll legal operations completed safely.\n");
    return 0;
}

Real-World Pattern: Using Pointer Arithmetic in a Custom Memory Buffer

Let's put it all together with a pattern you'll actually encounter: a simple write buffer that tracks its own current position using pointer arithmetic. This is the core idea behind arena allocators, packet serializers, and file format writers.

The idea is straightforward: you allocate a fixed block of memory, keep a write_ptr that starts at the beginning, and advance it each time you write data. Pointer arithmetic tells you how much space you've used (write_ptr - buffer_start) and how much you have left (buffer_end - write_ptr).

This pattern is used in real systems because it avoids repeated malloc calls and gives you cache-friendly contiguous storage. Game engines, network stacks, and embedded firmware all use variations of this. Understanding it requires being comfortable with pointer arithmetic: you need to write to the current position, advance past what you just wrote, and check bounds without ever losing track of where you started.

The code below shows a minimal version you can actually run — a byte buffer that serializes integers and strings one after another, with boundary checking at each step.

#include <stdio.h>
#include <string.h>   /* memcpy  */
#include <stdint.h>   /* uint8_t */
#include <stddef.h>   /* ptrdiff_t, size_t */

#define BUFFER_CAPACITY 64

typedef struct {
    uint8_t  storage[BUFFER_CAPACITY]; /* raw byte storage                        */
    uint8_t *write_ptr;                /* where the next byte will be written     */
    uint8_t *end_ptr;                  /* one-past-end sentinel for bounds checks */
} WriteBuffer;

void buffer_init(WriteBuffer *buf) {
    buf->write_ptr = buf->storage;                  /* start at the beginning     */
    buf->end_ptr   = buf->storage + BUFFER_CAPACITY;/* one past the last byte     */
}

/* Returns bytes used so far */
size_t buffer_used(const WriteBuffer *buf) {
    return (size_t)(buf->write_ptr - buf->storage); /* pointer subtraction = count */
}

/* Returns bytes remaining */
size_t buffer_remaining(const WriteBuffer *buf) {
    return (size_t)(buf->end_ptr - buf->write_ptr); /* space left to write into   */
}

/* Write a 32-bit integer into the buffer (big-endian) */
int buffer_write_int32(WriteBuffer *buf, int32_t value) {
    if (buffer_remaining(buf) < sizeof(int32_t)) {
        return -1;  /* not enough space */
    }
    /* memcpy is the safe way to write non-char data through a byte pointer */
    memcpy(buf->write_ptr, &value, sizeof(int32_t));
    buf->write_ptr += sizeof(int32_t); /* advance past the 4 bytes we just wrote */
    return 0;
}

/* Write a null-terminated string (without the null terminator) into the buffer */
int buffer_write_string(WriteBuffer *buf, const char *text) {
    size_t text_length = strlen(text);
    if (buffer_remaining(buf) < text_length) {
        return -1;  /* not enough space */
    }
    memcpy(buf->write_ptr, text, text_length);
    buf->write_ptr += text_length;     /* advance past the string bytes we wrote  */
    return 0;
}

int main(void) {
    WriteBuffer packet;
    buffer_init(&packet);

    printf("Buffer capacity: %d bytes\n", BUFFER_CAPACITY);
    printf("Initial — used: %zu, remaining: %zu\n",
           buffer_used(&packet), buffer_remaining(&packet));

    /* Write a 32-bit sensor ID */
    int32_t sensor_id = 4029;
    buffer_write_int32(&packet, sensor_id);
    printf("After writing int32 (%d) — used: %zu, remaining: %zu\n",
           sensor_id, buffer_used(&packet), buffer_remaining(&packet));

    /* Write a status string */
    const char *status = "SENSOR_OK";
    buffer_write_string(&packet, status);
    printf("After writing string (\"%s\") — used: %zu, remaining: %zu\n",
           status, buffer_used(&packet), buffer_remaining(&packet));

    /* Write another int */
    int32_t timestamp = 1718000000;
    buffer_write_int32(&packet, timestamp);
    printf("After writing timestamp (%d) — used: %zu, remaining: %zu\n",
           timestamp, buffer_used(&packet), buffer_remaining(&packet));

    /* Show the raw bytes written */
    printf("\nRaw bytes in buffer (%zu total):\n", buffer_used(&packet));
    for (uint8_t *p = packet.storage; p < packet.write_ptr; p++) {
        /* Print hex for non-printable bytes, char for printable ones */
        if (*p >= 32 && *p < 127)
            printf(" '%c'", *p);
        else
            printf(" %02X", *p);
    }
    printf("\n");

    return 0;
}

Debugging Pointer Arithmetic: How Sanitizers Catch the Bugs You Miss

Pointer arithmetic bugs are notoriously hard to reproduce. A buffer overflow might only crash when the next heap chunk is allocated. An off-by-one might corrupt data silently for weeks before manifesting as a production outage.

The tools that find these bugs don't rely on luck. AddressSanitizer (ASan) instruments every memory access at compile time, checking each pointer operation against the known bounds of the allocation. It catches overflows, use-after-free, and garbage pointer dereferences. It's not a debugger — it's a runtime safety net that terminates the program with a precise report at the first violation.

UndefinedBehaviorSanitizer (UBSan) catches the subtler errors: pointer arithmetic past the allowed bound, misaligned pointer operations, and strict aliasing violations. Together, ASan and UBSan should be part of your standard debug build for any C project that uses pointer arithmetic.

Valgrind (Memcheck) is the heavy artillery for heap corruption. It intercepts every malloc and free, tracking the validity and origin of every byte. When pointer arithmetic causes you to read uninitialised memory, Valgrind tells you exactly where the value came from.

The critical habit: always run with these tools during development and in CI. A single pointer arithmetic mistake that survives code review will eventually cause a production incident. Sanitizers make that mistake visible in the first test run.

#!/bin/bash
# Build with AddressSanitizer and UndefinedBehaviorSanitizer
# compile
clang -fsanitize=address,undefined -g -O1 -o program program.c
# run — ASan checks every pointer operation
./program
# If there's a bug, ASan will print a detailed report with:
#   - The exact line of the violation
#   - The allocation context
#   - The access direction (read/write) and offset
#
# Example ASan output for a one-past-end dereference:
# ==12345==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x...
# READ of size 4 at 0x... thread T0
#     #0 in main at pointer_test.c:15
#     #1 in ... libc_start_main ...
# 0x... is located 0 bytes after 20-byte region [0x...,0x...)
# allocated by thread T0 here:
#     #0 in malloc ...
#     #1 in main at pointer_test.c:10

Pointer Subtraction: The Only Integer Math That Returns a Meaningful Count

Most devs think pointer arithmetic is just increment and decrement. The real power is pointer subtraction. When you subtract two pointers of the same type pointing into the same array, C returns the number of elements between them — not bytes. This is critical for buffer traversal, memcpy sizing, and diagnostic logging. The compiler divides the byte difference by the type size automatically. For trading systems processing 100k messages per second, manual offset calculations introduce off-by-one errors that corrupt entire packet buffers. Use pointer subtraction to compute index distances safely. Never cast to (int*) and subtract bytes yourself. The moment you start tracking byte offsets manually in a memory region, you introduce undefined behavior. Remember: ptrdiff_t is the signed integer type for pointer differences. It guarantees enough range even on 64-bit systems. Use it. Your future self debugging a production crash at 3 AM will thank you.

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

int main() {
    int arr[] = {10, 20, 30, 40, 50};
    int *start = &arr[1];
    int *end   = &arr[4];

    ptrdiff_t count = end - start;
    printf("Elements between arr[1] and arr[4]: %td\n", count);

    // Wrong way: byte difference
    printf("Byte difference (WRONG): %zu\n", (size_t)((char*)end - (char*)start));

    return 0;
}

Comparison of Pointers: The Undefined Behavior Trap in Non-Contiguous Memory

Pointer comparison sounds safe. It's not. Comparing pointers that don't point into the same array (or one past the end) is undefined behavior. The C standard says relational operators (<, >, <=, >=) are only defined for pointers within the same aggregate object or its terminating sentinel. The pattern that kills production systems: comparing pointers from two different malloc() calls. Even if the addresses happen to compare correctly today on x86, the compiler is free to optimize that comparison out entirely. On embedded systems, this is a classic source of phantom bugs. The only safe comparisons are equality (==, !=) across any valid pointers and relational comparisons within the same array. If you need to compare positions across buffers, store indices, not pointers. This is a zero-cost abstraction — integers don't trigger UB.

#include <stdio.h>
#include <stdlib.h>

int main() {
    int *a = malloc(sizeof(int) * 3);
    int *b = malloc(sizeof(int) * 3);

    // Undefined behavior: pointers from different allocations
    if (a < b) {
        printf("a is before b (UB!)\n");
    }

    // Safe: restore structure by comparing indices
    int index_a = 0, index_b = 1;
    if (index_a < index_b) {
        printf("index_a < index_b (safe)\n");
    }

    free(a);
    free(b);
    return 0;
}