Storage Duration, Lifetime, and Ownership: How C Programs Retain Resources

C does not have destructors. That does not mean C lacks lifecycles. Every object possesses a storage duration, every resource holds acquisition and release boundaries, and every single error path must uphold these boundaries. Memory leaks, double-frees, dangling pointers, and leaked file handles in C all stem from ownership protocols failing to be properly expressed in the code structure.

Storage Duration Dictates How Long Storage Exists

Common storage durations in C include automatic, static, thread, and allocated. Storage duration answers the question: "When does this block of storage exist?" It does not equate to whether the object's value is valid, nor does it guarantee the resource still belongs to the current caller.

Storage duration is like warehouse rental. Object values and resource ownership are the goods stored inside. Just because the rental is active doesn't mean the goods still belong to you.

Automatic Objects Must Not Escape

Automatic objects generally reside in the stack frame. Once the function returns, their lifecycle is extinguished. Returning the address of a local object leaves a catastrophic dangling pointer.

int* bad(void) {
  int value = 42;
  return &value;
}

The address returned by this code previously pointed to value. After the function returns, that stack space is eligible for reuse. Subsequent reads or writes constitute undefined behavior. Sometimes it "looks like it still works" simply because the stack hasn't been overwritten yet.

Static Objects Are Global State

Objects with static storage duration exist for the entire lifecycle of the program. They are excellent for constant lookup tables and immutable configuration. However, mutable static objects introduce severe risks for concurrency, testing isolation, and initialization order.

static int global_counter;

void inc(void) {
  ++global_counter;
}

In a single-threaded context, this is trivial. In a multi-threaded context, it is a blatant data race. During testing, it retains state across unit tests. In library code, it destroys multi-instance isolation.

Static objects must either be strictly immutable, protected by synchronization, or refactored down into explicit context objects.

Dynamic Allocation Merely Acquires Storage

malloc returns a block of uninitialized storage that satisfies alignment requirements. It bears no responsibility for initializing business invariants. free releases this storage. Once freed, every pointer pointing to it instantly becomes a dangling pointer.

int* p = malloc(sizeof *p);
if (p == NULL) {
  return -1;
}
*p = 7;
free(p);
p = NULL;

Nullifying the pointer only neutralizes that specific variable p. Any other aliased pointers remain dangling. Consequently, ownership design cannot simply rely on "set to null after free."

Ownership Must Be Written Into the API

C APIs must explicitly declare who creates, who frees, who borrows, and who transfers. Unspoken ownership is a hidden liability.

typedef struct Image Image;

Image* image_load(const char* path);
void image_destroy(Image* image);
const unsigned char* image_pixels(const Image* image);

This interface clearly communicates three facts:

• image_load returns an owning pointer.
• image_destroy relinquishes the owning pointer.
• image_pixels returns a borrowed view; it must never be freed.

Naming, documentation, and types must align perfectly. If a return value requires the caller to free it, the function name and comments must unequivocally state so.

Error Paths Are Stress Tests for Resource Management

Resource leaks most frequently occur during premature failures. The "happy path" is usually coded correctly. Failure paths demand a systemic cleanup strategy.

int load_pair(const char* a, const char* b) {
  FILE* fa = NULL;
  FILE* fb = NULL;
  int rc = -1;

  fa = fopen(a, "rb");
  if (fa == NULL) goto cleanup;

  fb = fopen(b, "rb");
  if (fb == NULL) goto cleanup;

  rc = 0;

cleanup:
  if (fb != NULL) fclose(fb);
  if (fa != NULL) fclose(fa);
  return rc;
}

goto cleanup is not a sloppy shortcut in C. It centralizes resource deallocation, preventing you from manually rewriting the release logic for every single error branch. Complex functions should still be broken down; a cleanup block is not an excuse for monolithic methods.

Release Order Should Generally Be Reversed

Resources often harbor dependencies. A resource acquired later typically relies on one acquired earlier. Deallocation must proceed in reverse chronological order.

create context
  -> open file
    -> allocate buffer
      -> map region

cleanup:
  unmap region
  free buffer
  close file
  destroy context

This stack-like discipline is the conceptual precursor to C++'s RAII. In C, you must maintain it manually. In C++, it is handed off to destructors and member declaration order.

Owning and Borrowed Pointers Demand Distinct Naming

The C type system cannot natively express ownership. Naming and encapsulation must bridge the gap.

typedef struct Buffer {
  unsigned char* owned_data;
  size_t len;
} Buffer;

typedef struct Slice {
  const unsigned char* data;
  size_t len;
} Slice;

Buffer holds ownership. Slice merely observes. Never allow a borrowed object to execute a release operation. Never allow an owning object to be casually shallow-copied.

Initialization Functions Must Establish Invariants

Never leak a partially initialized object to a caller. An initialization function must either successfully establish full invariants or fail and clean up any resources acquired mid-flight.

typedef struct Writer {
  FILE* file;
  unsigned char* buffer;
  size_t capacity;
} Writer;

int writer_init(Writer* w, const char* path, size_t capacity);
void writer_deinit(Writer* w);

The caller provides the storage. writer_init populates the resources. writer_deinit frees the internal resources. This pattern is exceptionally well-suited for stack-allocated objects and embedded environments.

Copy Strategies Must Be Explicit

Structs containing resources must not implicitly permit = assignment. The C compiler will mindlessly copy the fields byte-by-byte. This duplicates pointer values, leading to two distinct objects believing they own the exact same resource.

Buffer a = buffer_create(1024);
Buffer b = a; /* HIGH RISK: Shallow copy */

Provide explicit clone or move style functions.

int buffer_clone(Buffer* dst, const Buffer* src);
Buffer buffer_move(Buffer* src);

A move-style function must transition the source object into a destructible but non-owning state.

Allocation Failure Is Normal Input

System memory exhaustion, quota caps, and container limits can all induce allocation failures. Reliable C code can never assume malloc will eternally succeed.

void* checked_realloc(void* old, size_t n) {
  void* next = realloc(old, n);
  if (next == NULL && n != 0) {
    return NULL;
  }
  return next;
}

If realloc fails, the old pointer remains valid. Blindly writing p = realloc(p, n) overwrites and loses the original pointer upon failure, guaranteeing a leak. These precise details must be scrutinized during code audits.

Resources Are Not Just Memory

Resources managed by C programs include:

• Heap memory.
• File descriptors.
• Sockets.
• Memory-mapped (mmap) regions.
• Mutexes.
• Threads.
• GPU buffers.
• Database handles.
• Temporary files.
• Authorization tokens.

Every single resource necessitates a corresponding release function. Every single resource has potential failure paths. Every single resource demands observation and logging.

Lifecycles and Concurrency Mutually Amplify Risks

In a single-threaded context, dangling pointers are perilous. In multi-threaded contexts, interleaved object releases and accesses violently mutate into use-after-free exploits.

Thread A: Reads shared->data
Thread B: free(shared)
Thread A: Continues using data

The solution is not just lazily slapping a lock on it. You must rigorously define object ownership, reference counting, shutdown protocols, join sequences, and exact resource release points. If an object is borrowed across multiple threads, all borrows must definitively conclude before destruction is allowed.

Diagnostic Tooling Must Traverse Error Paths

ASan catches use-after-free and out-of-bounds access. LSan detects memory leaks. UBSan flags some out-of-lifecycle access. However, tools can only analyze code paths that actually execute. Error path testing cannot be neglected by solely running "happy path" suites.

clang -std=c23 -g -O1 \
  -fsanitize=address,undefined \
  resource_test.c

This is highly effective when paired with fault injection:

• Simulate malloc failures.
• Simulate fopen failures.
• Simulate mid-flight parsing errors.
• Simulate inadequate permissions.
• Simulate timeouts and cancellations.

API Documentation Must Integrate Release Protocols

Every function returning a pointer must answer:

• Can the return value be null?
• Does the caller now own it?
• Which specific function must be used to free it?
• Is it safe to use across threads?
• Can the borrowed pointer be safely cached?
• If it fails, what happens to previously allocated resources?
• Is it permissible to free it from within a callback?
• Is there a fallback/degradation strategy?

An API devoid of release protocols ultimately forces developers to rely on human memory for resource management.

Engineering Checklist

• Every create/open/acquire has a corresponding destroy/close/release.
• Every error path successfully funnels into a cleanup phase.
• Release order mirrors the exact inverse of acquisition order.
• realloc utilizes a temporary pointer to receive the result.
• Borrowed pointers never execute release operations.
• Owning objects explicitly ban implicit shallow copying.
• Static mutable state is relentlessly audited for concurrency.
• Resource failure paths are backed by dedicated test coverage.
• Sanitizer builds are configured to traverse error paths.
• Resource release logs can be correlated with their originating request or task.

Summary

Resource safety in C is not magically handled by the language; it is enforced through unambiguous ownership protocols and uniform cleanup structures. Storage duration tells you when the storage physically exists. Lifecycle tells you when the object is logically valid. Ownership tells you who is contractually obligated to release the resource. Blurring the lines between any of these three will inevitably magnify into production risks across error paths, concurrency boundaries, or module interfaces.