Dynamic Memory, File IO, and the Preprocessor: Moving C Programs Toward Engineering

When a program only manages a few fixed variables, stack objects suffice. When input sizes are only known at runtime, the program requires dynamic memory. When data must be read from or written to disk, the program requires file IO. When code must compile across different platforms or configurations, the program interacts with the preprocessor. These three elements elevate a C program from a simple exercise to an engineering project, but they also introduce risks involving resource release, error paths, and conditional compilation.

Dynamic Memory Solves Runtime Sizing

If an array's length is unknown at compile time, it must be allocated dynamically.

#include <stdlib.h>

int* values = malloc(count * sizeof *values);
if (values == NULL) {
  return -1;
}

malloc requests a block of storage from the heap. It returns a void*. If the request fails, it returns NULL. This is not a rare event; container limits, memory pressure, and quotas can all trigger failures.

sizeof *ptr Reduces Type Duplication

Recommended style:

int* values = malloc(count * sizeof *values);

Not recommended:

int* values = malloc(count * sizeof(int));

If the type of values changes in the future, the first approach adapts automatically. The second approach easily leaves the old type behind, leading to mismatched allocation sizes.

Checking for Multiplication Overflow

When allocating arrays, count * sizeof *values can overflow. After an overflow, the allocated memory is smaller than requested, causing subsequent writes to go out-of-bounds.

if (count > SIZE_MAX / sizeof *values) {
  return -1;
}
int* values = malloc(count * sizeof *values);

Such checks are especially critical when parsing external inputs. Security vulnerabilities frequently originate from length calculation overflows.

calloc Zeroes the Memory

int* values = calloc(count, sizeof *values);

calloc allocates and zeroes out the memory. It typically also handles the multiplication size check for you. However, you must still check the return value. Zeroing memory does not initialize all business invariants; it merely sets the object representation to zero.

realloc Requires a Temporary Pointer

Incorrect usage:

buffer = realloc(buffer, new_size);

If it fails, the old pointer is lost, resulting in a memory leak. Correct usage:

void* next = realloc(buffer, new_size);
if (next == NULL) {
  return -1;
}
buffer = next;

The semantics of realloc are nuanced. Engineering code must explicitly handle these failure paths.

free Releases Heap Memory

free(values);
values = NULL;

free(NULL) is safe. Calling free repeatedly on the same non-null pointer is a critical error (double-free). Nullifying the current pointer after freeing only protects that specific variable; it does not protect other aliased pointers.

p ─────┐
q ─────┴──> heap block
free(p)
q is still dangling

Robust ownership design is far more important than just "setting to null after free."

Opening and Closing Files

The C standard library uses FILE* to represent file streams.

#include <stdio.h>

FILE* file = fopen("data.txt", "rb");
if (file == NULL) {
  return -1;
}

fclose(file);

fopen can fail for many reasons:

• The file does not exist.
• Insufficient permissions.
• Incorrect path.
• File descriptor exhaustion.
• Sandbox restrictions.

You must always check the return value.

Reading Files

unsigned char buffer[1024];
size_t n = fread(buffer, 1, sizeof buffer, file);

fread returns the actual number of bytes read. Reading fewer bytes than requested is not necessarily an error; it might just be the end of the file. You must use ferror and feof to differentiate.

if (ferror(file)) {
  /* Read error occurred */
}

Never assume a single read call will fetch the entire file.

Writing Files

size_t n = fwrite(buffer, 1, length, file);
if (n != length) {
  /* Write failed or was partial */
}

Writes can fail. Disk full errors, permission drops, and network file system disconnects happen in the real world. The return value of write operations must be checked. Production systems must also consider fsync, temporary files, and atomic replacements.

Centralizing Error Path Cleanup

Dynamic memory and file IO frequently appear together. Centralized cleanup prevents resource leaks.

int load(const char* path) {
  FILE* file = NULL;
  unsigned char* data = NULL;
  int rc = -1;

  file = fopen(path, "rb");
  if (file == NULL) goto cleanup;

  data = malloc(4096);
  if (data == NULL) goto cleanup;

  rc = 0;

cleanup:
  free(data);
  if (file != NULL) fclose(file);
  return rc;
}

C's goto cleanup is a standard resource release pattern. It does not encourage chaotic jumping.

The Preprocessor Runs Before Compilation

The preprocessor handles #include, #define, conditional compilation, and other directives. It operates before any semantic analysis occurs.

#define BUFFER_SIZE 4096

#if defined(_WIN32)
#define PATH_SEP '\\'
#else
#define PATH_SEP '/'
#endif

The preprocessor is akin to a text manipulation engine. It does not understand C's type system. If a macro is written poorly, the compiler only sees the broken, expanded code.

Macro Constants vs. const

Macro constant:

#define MAX_COUNT 1024

const object:

static const int max_count = 1024;

Macros have no types and no scope. const variables have types and obey scope rules. If a constant can be expressed using const or an enum, do not default to using a macro.

Be Cautious with Function Macros

#define SQUARE(x) ((x) * (x))

This looks like a function, but it is raw text replacement.

int y = SQUARE(i++);

This expands to execute i++ twice. Such side effects are highly dangerous. In modern C, many function macros can be safely replaced with static inline functions.

static inline int square_int(int x) {
  return x * x;
}

Conditional Compilation Must Be Auditable

Cross-platform code heavily utilizes conditional compilation.

#if defined(__linux__)
  /* Linux path */
#elif defined(_WIN32)
  /* Windows path */
#else
#error "unsupported platform"
#endif

Every branch must be compilable in your CI pipeline. Conditional branches that are never compiled usually explode precisely when you urgently need to migrate to that platform.

Header File Inclusion Order

Header files should strive to be self-contained. If a header file requires a specific type, it should #include the corresponding declaration itself, rather than demanding the caller include it beforehand.

#ifndef BUFFER_H
#define BUFFER_H

#include <stddef.h>

typedef struct Buffer {
  unsigned char* data;
  size_t size;
} Buffer;

#endif

This makes the header's contract much more stable.

Engineering Risks

Common risks associated with dynamic memory, file IO, and the preprocessor:

• Ignoring malloc return values.
• Allocation size multiplication overflows.
• realloc failures leaking the old pointer.
• Forgetting to free or executing a double-free.
• Unhandled file open failures.
• Treating partial reads/writes as successes.
• Macro arguments evaluating side effects multiple times.
• Conditional compilation branches rotting without CI coverage.
• Header macros polluting the global namespace.
• Error paths bypassing resource release.

These issues all demand rigorous testing, logging, and code auditing.

Summary

Dynamic memory empowers programs to handle runtime scales. File IO enables programs to exchange data with the outside world. The preprocessor adapts source code to diverse platforms and configurations. Together, they transition C programs into real-world engineering, but simultaneously introduce engineering burdens: resource release, error handling, permissions, boundaries, and observability. From here on out, C is no longer just a syntax exercise; it is systems programming.