DEV Community: Manish Sah

Rust vs C: Why 'Index Out of Bounds' Is a Feature, Not a Bug

Manish Sah — Thu, 23 Jul 2026 06:38:58 +0000

C lets you read and write past the end of an array without complaint. Rust refuses. That one design decision is the difference between a crash and a remote code execution vulnerability.

Imagine you're building a feature where users can select an item from a list. In Rust, if you try to pull index 10 out of a 5-element array, the program stops dead in its tracks:

// src/main.rs
use std::io;

fn main() {
    let a = [1, 2, 3, 4, 5];

    println!("Please enter an array index.");

    let mut index = String::new();

    io::stdin()
        .read_line(&mut index)
        .expect("Failed to read line");

    let index: usize = index
        .trim()
        .parse()
        .expect("Index entered was not a number");

    let element = a[index];

    println!("The value of the element at index {index} is: {element}");
}

Feed it 10, and Rust panics instantly:

thread 'main' panicked at src/main.rs:19:19:
index out of bounds: the len is 5 but the index is 10
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

This is a runtime check, not a compile-time one — Rust doesn't know at compile time what index will be, so it verifies bounds every time you index into the array, then deliberately crashes rather than continue.

But what happens in C in this exact situation? And why does C's behavior here account for some of the most damaging security exploits in software history?

1. C: Raw Pointer Math, No Guardrails

C takes the opposite approach: it assumes you know what you're doing, so indexing performs zero bounds checking. a[10] is really just:

address = start_address_of_array + (index * element_size)

The CPU jumps straight to that computed address and reads (or writes) whatever is sitting there — no validation involved.

#include <stdio.h>

int main() {
    int a[5] = {1, 2, 3, 4, 5};

    // Index 10 is well past the 5-element array
    printf("Value: %d\n", a[10]);

    return 0;
}

What actually happens is undefined behavior, which in practice means one of:

Garbage data — it prints whatever bits happen to live in adjacent memory.
Segmentation fault — if the computed address falls outside memory your process is allowed to touch, the OS kills the process.
Silent memory corruption — if you write past the boundary (a[10] = 99), you silently overwrite whatever variable happens to occupy that memory.

2. Why This Is a Security Problem, Not Just a Bug

Here's a simplified picture of how a C function's local variables can be laid out on the stack:

[ High Memory Address ]
+-----------------------------------+
|   Return Address                  |  <-- Tells CPU where to jump next
+-----------------------------------+
|   Saved Frame Pointer             |
+-----------------------------------+
|   admin_password = "Secret"       |  <-- Neighboring variable
+-----------------------------------+
|   a[4]  |  a[3]  |  a[2]  |  a[1] |  <-- Your array (5 integers)
+-----------------------------------+
[ Low Memory Address ]

Caveat: this is illustrative, not guaranteed. Real compilers reorder locals, insert padding, and add mitigations like stack canaries and ASLR (address space layout randomization) specifically to make this layout unpredictable. But the underlying principle holds: on the stack, your array and other local variables — including, eventually, the return address — live in contiguous memory with nothing stopping you from walking off the end of one into another.

3. How Attackers Exploit Unchecked Array Access

Unchecked bounds lead to two main vulnerability classes.

A. Out-of-Bounds Read (Information Leak)

If an attacker can influence which index or offset gets read, they can pull adjacent memory out of the process — including secrets that were never meant to leave it, like session tokens or other variables sitting nearby in memory.

B. Out-of-Bounds Write / Buffer Overflow (Arbitrary Code Execution)

If an application lets you write past the end of an array, you can start overwriting things that control program flow.

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

void secret_admin_panel() {
    printf("Access Granted: Welcome Admin!\n");
}

void user_login() {
    int is_admin = 0;              // Flag: 0 = User, 1 = Admin
    char username[8];              // Array sized for 8 characters

    printf("Enter username: ");
    gets(username);                // UNSAFE: no length checking

    if (is_admin != 0) {
        secret_admin_panel();
    } else {
        printf("Hello, regular user.\n");
    }
}

gets() is used here deliberately as a textbook example — it was actually removed from the C standard in C11 because it's impossible to use safely, but plenty of legacy code and CTF challenges still rely on this exact pattern.

Step by step:

username gets 8 bytes, and is_admin happens to sit next to it on the stack.
Input AAAAAAAAA (9 characters) overflows the buffer by one byte, overwriting is_admin.
is_admin is no longer 0, so if (is_admin != 0) evaluates true — admin access granted.
With a larger payload, an attacker can keep writing past local variables entirely and overwrite the return address. When the function returns, the CPU jumps straight into attacker-controlled memory.

4. Rust's Answer: Panic by Default, `Option` When You Want Control

Rust's decision to panic on out-of-bounds access is deliberate: fail loudly and immediately rather than silently corrupt memory. But indexing with [] isn't your only option. If you want to handle the invalid case yourself instead of crashing:

let a = [1, 2, 3, 4, 5];

match a.get(10) {
    Some(value) => println!("Value: {value}"),
    None => println!("Index out of bounds — handled gracefully"),
}

a.get(index) returns Option<&T> — None instead of a panic. This is the idiomatic way to handle user-controlled indices in production Rust code: [] when you're certain the index is valid (and want a loud crash if you're wrong), .get() when the index comes from outside and you want to handle failure explicitly.

Quick Comparison

Feature	C	Rust
Out-of-bounds access	Undefined behavior (reads/writes raw memory)	Panics by default; `.get()` returns `None`
When is it checked	Never	Every access, at runtime
Security risk	Critical — buffer overflows, remote code execution	Low — safe Rust can't produce this class of memory corruption
Escape hatch	None (by design)	`.get()` / `Option`

Note the "safe Rust" qualifier: inside an unsafe block, Rust lets you opt back into raw pointer access with the same risks C has. The safety guarantee applies to code that doesn't reach for unsafe.

Wrap-Up

When Rust panics on a bad index, it can feel like the language is getting in your way. But that's the point — the crash is the safety mechanism. C's willingness to let you read and write past the end of an array isn't a missing feature; it's a design tradeoff from an era that prioritized raw performance over runtime checks, and it's directly responsible for decades of the worst vulnerabilities in software history.

Have you run into a memory bug like this in production? Let's talk in the comments.

Source: Rust documentation on slices and Option

Rust Strings Demystified: Literals, Slices, and Fat Pointers Under the Hood

Manish Sah — Wed, 22 Jul 2026 03:54:29 +0000

When developers switch to Rust from high-level languages like Python or JavaScript, one of the first mental speedbumps is the string system.

Why are there two main string types (String vs &str)? What actually happens when a function returns "Yummy!"? And why is a string slice called a "fat pointer"?

In this post we'll look under the hood at how Rust lays out string literals, string slices, and pointers in memory — and why this design makes Rust strings fast and memory-efficient.

1. Literal vs. Slice

Two terms get conflated a lot, so let's separate them:

Literal: text hardcoded directly into your .rs source file (e.g., "Hello, world!").
Slice (&str): a view into a contiguous run of valid UTF-8 bytes somewhere in memory, without owning them.

The relationship between the two:

Every string literal is a string slice, but not every string slice is a string literal.

Example

fn main() {
    // 1. A string literal — embedded in the compiled binary.
    // Type: &'static str
    let literal: &str = "Hello, world!";

    // 2. A dynamic String — allocated at runtime on the heap.
    let mut user_input = String::new();
    user_input.push_str("Rustacean");

    // 3. A slice into that heap string.
    // Type: &str (points into user_input's heap buffer, not the binary)
    let dynamic_slice: &str = &user_input[0..4]; // "Rust"

    // Both are &str, so the same function accepts either.
    print_slice(literal);       // "Hello, world!"
    print_slice(dynamic_slice); // "Rust"
}

fn print_slice(slice: &str) {
    println!("Printing slice: {}", slice);
}

literal is a string literal, so its type is &'static str — it's embedded directly in the binary.
dynamic_slice is a valid &str, but not a literal — it was carved out of user_input at runtime and didn't exist in your source code.

2. Normal Pointer vs. Fat Pointer

In C, a string pointer is a plain 8-byte address (on 64-bit). String functions scan forward byte-by-byte until they hit a null terminator (\0).

Rust drops null terminators entirely. Instead, &str is a fat pointer: two 64-bit fields packed back to back, 16 bytes total on a 64-bit target.

┌─────────────────────────┬─────────────────────────┐
│     Pointer (8 bytes)   │     Length (8 bytes)    │
├─────────────────────────┼─────────────────────────┤
│  0x00007FFF00401050     │            6             │
└─────────────────────────┴─────────────────────────┘

Pointer: the address of the first byte.
Length: the number of bytes in the slice.

Note: this ptr-then-length picture is the right mental model, but Rust doesn't guarantee that exact field ordering as part of its stable ABI. What is guaranteed is that a &str/&[T] reference is two machine words wide.

3. What Happens When a Function Returns `"Yummy!"`?

fn picky_eater(food: &str) -> &str {
    if food == "strawberry" {
        "Yummy!"
    } else if food == "potato" {
        "I guess I can eat that."
    } else {
        "No thanks!"
    }
}

Step A: The read-only data segment (`.rodata`)

At compile time, string literals like "Yummy!" get written into the binary's read-only data segment (.rodata). When the OS loads the binary, that data lands at a fixed address in RAM for the entire life of the program — which is exactly why literals get the 'static lifetime.

Say the OS loads "Yummy!" at 0x00007FFF00401050:

Address	Byte (hex)	Character
`0x00007FFF00401050`	`0x59`	`'Y'`
`0x00007FFF00401051`	`0x75`	`'u'`
`0x00007FFF00401052`	`0x6D`	`'m'`
`0x00007FFF00401053`	`0x6D`	`'m'`
`0x00007FFF00401054`	`0x79`	`'y'`
`0x00007FFF00401055`	`0x21`	`'!'`

Step B: Constructing and returning the fat pointer

Rust doesn't copy those 6 bytes onto the stack. It just constructs a 16-byte fat pointer:

Pointer = 0x00007FFF00401050
Length = 6

Since the underlying bytes live in .rodata for the program's entire lifetime, returning this pointer is completely safe — you're never pointing at stack memory that disappears when the function returns.

4. Zero-Cost Slicing (and its one sharp edge)

Because length is metadata on the pointer itself, sub-slicing is zero-cost:

let full: &str = "Yummy!";
let sub: &str = &full[1..5]; // "ummy"

No new allocation, no copy — just a new 16-byte fat pointer:

Memory:     [  'Y'  |  'u'  |  'm'  |  'm'  |  'y'  |  '!'  ]
Address:     ...1050  ...1051  ...1052  ...1053  ...1054  ...1055
             ▲        ▲                             ▲
             │        └──────────────┬──────────────┘
             │                       │
`full`:  ptr = ...1050, len = 6      │
`sub`:   ptr = ...1051, len = 4 ─────┘

full: pointer = 0x...1050, length = 6 ("Yummy!")
sub: pointer = 0x...1051 (offset by 1 byte), length = 4 ("ummy")

Both slices point into the exact same memory.

The gotcha: those slice indices are byte offsets, and Rust requires them to land on UTF-8 character boundaries. &full[1..5] works because every character in "Yummy!" is a single ASCII byte. Slice a multi-byte character (say, an emoji or accented letter) in the middle of its encoding, and Rust panics at runtime rather than handing back corrupted UTF-8. Coming from Python, where str[1:5] just silently does the "wrong" thing on multi-byte content, this is worth internalizing early.

5. Summary Cheat Sheet

Concept	Definition	Lifetime / Memory	Size
Literal	Text hardcoded in source (`"..."`).	`'static`, lives in `.rodata`.	Embedded in the binary.
Slice (`&str`)	A view (pointer + length) into valid UTF-8 bytes.	Depends on what it borrows.	16 bytes (fat pointer).
`String`	Owned, growable, heap-allocated UTF-8 buffer.	RAII — dropped when it goes out of scope.	24 bytes (pointer, length, and capacity fields).

Why this design matters

O(1) length lookups — .len() costs nothing at runtime; the length is already sitting in the fat pointer.
Zero-copy passing — handing a 1 GB string slice to a function copies 16 bytes of pointer metadata, not the string.