The Ilusion of Arrays: Pointer Casting, and the Danger of memory Reinterpretation

When optimizing software to run as fast as possible, developers tend to hit a wall with high-level data structures. To squeeze every inch of performance out of a processor, we have to stop looking at arrays as safe little boxes, and start lookin at RAM for what it really is: a MASSIVE, contiguous strip of single bytes!!!
One of the most powerful optimization tricks in C, C++, and algo unsafe Rust is Pointer Casting, reinterpreting an array of 1 byte-data (u8) as an array of 4 bytes (u32). But this raw pointer comes with a high risk of hardware crashes. Here’s why:

The Optimization: Why the bother of casting u8 to u32?

A processor executes instructions in CPU CYCLES. If you need to read 4 bytes of data, a naive approach processes it through u8 (1 byte) pointer.
Cycles:

1. Load Byte 0
2. Load Byte 1
3. Load Byte 2
4. Load Byte 3

To optimize this, we change the “glasses” (just to make an analogy) the CPU is currently wearing. By taking the starting address of that u8 array and telling the compiler “Hey, pretend this is actually 🤓 a pointer of u32 data”, we change the memory stride.

Wait, wtf is a memory stride?

A memory stride is the distance in bytes between consecutive elements in memory along a particular dimension of an array.
Let’s make an example:

Array: [10, 20, 30, 40]
Type: uint32 (4 bytes per number)

Inside the memory will be:

Address: 1000   1004   1008   1012
Value:    10     20     30     40

• To go from 10 to 20, you have to move 4 bytes
• To go from 20 to 30, you move another 4 bytes So: stride = 4

Result when we “change the glasses”

Now when we tell the CPU to read index 0, it uses a 32-bit hardware register in order to swallow Bytes 0, 1, 2, and 3 simultaneously; which leads to:

• Cycle 1: Load Bytes 0, 1, 2, and also 3!!!!!!! We just made the memory read almost 400% faster. However, lying to the compiler about the shape of your memory could open two massive failures at a hardware level…

Problem 1: Alignment Fault

Processors are wired to expect certain data types to align with specific memory boundaries:

• An u8 (1 byte) can start at any addres
• A u32 (4 bytes) is strictly expected to start at an addres that is perfectly dividisible by 4 (0, 4, 8…)

If you have an u8 array, and you decide to put on your u32 glasses starting at Address 1, you just created an Unaligned Pointer.
So, when you ask the CPU to read a 4-byte chunk starting at Address 1, the hardware struggles. Some processors (like modern intel x86) will silently fix the mistake behind the scenes. But processors liek ARM chips found in movile devices, consoles or embedded systems, physically can’t do it. So they will instantly panic and triggfer a Fatal Alignment Fault.

Problem 2: Modulo Trap

Even if your starting Address is perfectly aligned, the overall size of your memory buffer can kill the program if it doesn’t divide perfectly into your new stride.

Let’s imagine that you have a raw u8 buffer which is exactly 17 bytes long. Then you cast the pointer to u32 in order to read it faster

17 modulo 4 = 1...

This means that you have 4 perfect chunks , but 1 trailing byte remaining…
So... when you loop through the memory with your u32 glasses:

• Index [0]: Reads bytes 0-3 (Safe…)
• Index [1]: Reads bytes 4-7 (Safe…)
• Index [2]: Reads bytes 8-11 (Safe…)
• Index [3]: Reads bytes 12-15 (Safe…)
• Index [4]: Reads byte 16... and bytes 17, 18, and 19 💀💀💀 Since you told the CPU it was reading a 4 byte structure.. It blindly reads past the end of your 17 byte buffer…

If bytes 17, 18, and 19 belong to the Operating System's restricted memory, the OS kills your program with a** Segmentation Fault** for trespassing.
Worse, if those bytes belong to another variable inside your own program, the CPU reads or overwrites them silently. Your program keeps running but with corrupted data… This is the definition of Undefined Behavior (UB). Good luck with that.

C/C++ vs. Safe Rust

In C and C++, the compiler implicitly trusts the developer. If you cast a char* to an int*, the compiler assumes you have manually verified the alignment and modulo math. When human error inevitably occurs, it results in security vulnerabilities.
Rust solves this by splitting the logic:

1. unsafe Rust: You can still perform raw pointer casting using std::slice::from_raw_parts and pointer casting (as *const u32). But you must wrap it in an unsafe {} block, taking personal responsibility for the math. If it crashes, you know exactly which block of code to blame!!!. 2. Safe Rust (Zero-Cost Abstractions): Instead of manually casting pointers, safe Rust provides methods like .copy_from_slice(), .copy_within(), or .try_into(). When you use these, the Rust compiler checks the alignment and array lengths at compile time or safely handles them under the hood. It compiles down to the exact same hyper-efficient hardware instructions (like memmove or SIMD loads) that a manual C-pointer cast would achieve, but mathematically guarantees you cannot trigger an Alignment Fault or step out of bounds.