Object Representation, Pointers, and Aliasing: How C Views Memory

The power of C stems from a simple model: objects occupy a segment of storage, pointers hold addresses, and expressions interpret that storage according to a type. This model is close enough to the machine to be fast, and close enough to be dangerous. If you only view a pointer as "something that accesses variables," you will fail to grasp alignment, aliasing, object representation, effective types, and how the optimizer sees your code. Many out-of-bounds reads, misaligned accesses, and permission bypasses originate from the misconception that "visible bytes" means "readable/writable as any type."

An Object is Not a Variable Name

A variable name is an identifier in source code. An object is a region of storage at runtime. Objects have a size, an alignment, a storage duration, and a value. An object might have a name, or it might be anonymous. The storage returned by malloc can be used to form objects in C, but the storage itself isn't intrinsically bound to a specific, named variable type forever.

int x = 42;
int* p = &x;

x is a named int object. The value of p is the address of that object. *p interprets that storage specifically through the lens of the int type. Types are not mere comments; they dictate read/write width, alignment, and aliasing rules for the compiler.

Object Representation is a Byte-Level Reality

The C standard allows inspecting object representation via character types. This means you can dissect any object into bytes. However, observing bytes does not grant you the right to arbitrarily reinterpret them as a completely different type.

#include <stdio.h>

void dump_int(int value) {
  unsigned char* bytes = (unsigned char*)&value;
  for (size_t i = 0; i < sizeof value; ++i) {
    printf("%02x\n", bytes[i]);
  }
}

This snippet reads the object representation of an int. It is useful for debugging endianness, padding, and protocol serialization. But if you attempt to read those bytes directly as another struct, you invite aliasing and alignment disasters.

Endianness Only Explains Byte Order for Multi-Byte Objects

Endianness dictates how the bytes of a multi-byte integer are arranged in memory. Little-endian machines place the least significant byte at the lowest address. Big-endian machines place the most significant byte at the lowest address. Endianness does not alter the numeric value, only the object representation.

uint32_t value = 0x11223344

Little-endian memory:
Low address -> 44 33 22 11 -> High address

Big-endian memory:
Low address -> 11 22 33 44 -> High address

Network protocols, file formats, and cross-platform caches must explicitly dictate their byte order. Never allow your current CPU's endianness to implicitly leak into persistent formats.

Alignment is a Joint Constraint of Hardware and ABI

Many types demand that their addresses align to specific boundaries. An int might require a 4-byte boundary. A double might require an 8-byte boundary. Struct members insert padding to satisfy these constraints.

struct Packet {
  char tag;
  int length;
};

This struct is rarely 5 bytes. tag is likely followed by 3 bytes of padding. length begins at an address divisible by 4. This ensures efficient CPU access and conforms to ABI conventions.

offset 0: tag
offset 1: padding
offset 2: padding
offset 3: padding
offset 4: length[0]
offset 5: length[1]
offset 6: length[2]
offset 7: length[3]

Force-casting a byte stream from a network packet into a struct pointer usually triggers endianness, padding, and alignment violations simultaneously.

Pointer Values Are Not Ordinary Integers

A pointer holds a value that locates an object. It can be cast to an integer type and back, but portability is severely limited. Pointer arithmetic is strictly defined only within the bounds of a single array object. Forming a pointer exactly one element past the end of an array is legal, but dereferencing it is not.

int a[4] = {1, 2, 3, 4};
int* end = a + 4;

end is a legal "one-past" pointer. *end is an out-of-bounds access. If the optimizer is aware of the array's length, it can assume that out-of-bounds reads never happen and radically reorder your logic.

A Null Pointer is Not Syntactic Sugar for Address 0

A null pointer means "pointing to no object or function." The implementation may represent it using any bit pattern. 0, NULL, or C23's nullptr in source code all invoke null pointer constant semantics. In engineering, treat a null pointer strictly as a state, never as an integer address.

int* p = NULL;
if (p != NULL) {
  *p = 1;
}

The null pointer check must occur before dereferencing. Checking after dereferencing is utterly useless because the program has already violated language guarantees.

Effective Types Govern Which Aliases Are Valid

The "effective type" is the cornerstone of C optimization boundaries. Compilers assume that pointers of incompatible types will not point to the same object. This is the foundation of "strict aliasing."

float break_aliasing(int* p) {
  float* fp = (float*)p;
  *p = 0x3f800000;
  return *fp;
}

This code attempts to read int storage as a float. It is often mistakenly used to "interpret bit patterns," but it heavily violates aliasing rules. The optimizer might assume int* and float* do not alias, resulting in completely unexpected logic flow.

The safe approach is using memcpy to copy the object representation.

#include <string.h>

float bits_to_float(unsigned int bits) {
  float value;
  memcpy(&value, &bits, sizeof value);
  return value;
}

Modern compilers routinely optimize small memcpy calls into simple register moves. This expresses the byte-copying intent perfectly without breaking aliasing rules.

Character Types Are the Window Into Aliasing Rules

char, signed char, and unsigned char are legally permitted to inspect any object representation. This forms the basis for serialization, hashing, and debugging dumps.

void wipe(void* p, size_t n) {
  unsigned char* bytes = p;
  for (size_t i = 0; i < n; ++i) {
    bytes[i] = 0;
  }
}

Functions like this access memory byte-by-byte. It is perfectly suited for zeroing out a buffer. However, if an object contains padding, those padding bytes may hold unspecified values. Writing an entire struct directly to a file dumps the padding as well, introducing severe information leaks and audit risks.

restrict is an Exclusive Promise to the Optimizer

The restrict qualifier declares that, for the lifetime of the pointer, the object it points to will not be accessed by any other pointer not based on it. It is a crucial tool for writing high-performance manual memory routines. However, it is not merely a hint; it is a rigid promise from the programmer. If the promise is broken, it results in undefined behavior.

void saxpy(size_t n, float a,
           const float* restrict x,
           float* restrict y) {
  for (size_t i = 0; i < n; ++i) {
    y[i] = a * x[i] + y[i];
  }
}

If x and y actually overlap, the optimizer is still legally allowed to generate code assuming they don't. Therefore, restrict must only be used in low-level routines with crystal-clear boundary constraints.

Struct Layout Does Not Equal Protocol Layout

Structs are tailored for expressing objects in memory. Protocols are tailored for expressing byte streams across systems. They appear similar but are fundamentally different abstractions.

In engineering, you must write explicit parsing functions to convert a byte stream into a struct object. Never let a packed struct serve as your default protocol strategy. packed can enforce misaligned access, severely degrading both performance and portability.

Memory Copying Is Not a Universal Panacea for Object Copying

memcpy copies the raw object representation. For pure Plain Old Data (POD) C structs, this is often fine. But for structs containing resource handles, internal pointers, or synchronization primitives, a shallow copy merely duplicates the handle value, not the resource ownership.

typedef struct Buffer {
  char* data;
  size_t len;
} Buffer;

Copying the bytes of Buffer simply results in two objects pointing to the exact same data block. If both objects attempt to free it, you get a double-free crash. This is precisely why C requires strict ownership conventions.

Debugging Object Representation Requires Context

When inspecting memory, you must simultaneously log:

• Type.
• Size.
• Alignment.
• Endianness.
• Compiler flags.
• Target architecture.
• Presence of padding.
• Validation across the object's lifecycle.

clang -std=c23 -g -fsanitize=address,undefined alias.c

ASan detects out-of-bounds access and use-after-free. UBSan detects misaligned access and illegal conversions. But they cannot mathematically prove that all your aliasing logic is flawless. Code audits must still be driven by a deep understanding of effective types.

Engineering Checklist

• Never blindly cast arbitrary byte streams directly into struct pointers.
• Use memcpy for bit-pattern conversions.
• Never rely on the content of struct padding.
• Explicitly define endianness and field widths for cross-platform formats.
• Audit the caller's contract rigorously when using restrict.
• Document ABI sizes and alignments for public-facing structs.
• Confine pointer arithmetic strictly within array boundaries.
• Complete null pointer checks before dereferencing.
• Isolate memory dumps to prevent privilege and privacy leaks.
• Enable ASan/UBSan paths in CI.

Summary

C's memory model is not "cast any address to anything." It is a low-level contract built entirely around objects, representations, types, alignments, and aliasing rules. Pointers pull your program closer to the machine, bypassing numerous protective layers. Writing reliable C means confirming—before every memory interpretation—that the object exists, the type aligns, the alignment is satisfied, and the lifecycle remains valid.