Safe Memory Resizing with realloc()

The Need for Resizable Memory

Imagine you are implementing a gateway that logs CAN messages. You might start by allocating space for 100 messages, but what happens when the 101st message arrives? A fixed-size array will fail. The naive solution—allocating a huge buffer upfront—is wasteful and often impractical in memory-constrained embedded systems.

The realloc() function provides the elegant solution: it allows you to change the size of an existing memory allocation.

The function is declared in <stdlib.h> as:
void* realloc(void* ptr, size_t new_size);

• ptr: A pointer to a memory block previously allocated by malloc(), calloc(), or realloc().
• new_size: The new size for the memory block, in bytes.

It returns a pointer to the resized memory block. Critically, if realloc() succeeds, the contents of the block are preserved up to the minimum of the old and new sizes.

How realloc() Works: The Two Scenarios

When you call realloc(), one of two things can happen if the request is successful.

1. In-place Expansion: If there is sufficient free memory immediately following your existing block, realloc() may simply expand the block into that space. In this case, the memory address of your block does not change.
2. Relocation: If there is not enough contiguous space to expand the block, realloc() will:
   a. Find a new, larger memory block elsewhere on the heap.
   b. Copy the contents from the old block to the new one.
   c. Free the old memory block.
   d. Return the address of the new block.

This image provides a clear visual summary of these two behaviors.

The fact that realloc() might move your memory block is the source of its power and its primary pitfall.

The Danger of Naive realloc() Usage

Because realloc() might return a new address, you must always update your pointer with its return value. A common but dangerous pattern looks like this:

// DANGEROUS - DO NOT DO THIS
ptr = realloc(ptr, new_size); 

This single line of code hides a critical flaw. realloc() returns NULL if it fails to allocate the requested memory.

Consider what happens if realloc fails in the code above:

1. realloc() returns NULL.
2. This NULL value is assigned to ptr, overwriting the original address of your memory block.
3. The original memory block is now lost. You have no pointer to it, so you can neither access its data nor free() it.

This is a classic memory leak. In long-running systems like automotive ECUs, even small, repeated leaks can eventually exhaust system memory and lead to catastrophic failure.

The Safe realloc() Pattern

To use realloc() safely, you must use a temporary pointer to store its return value. This allows you to handle the failure case without losing your original memory block.

Here is the robust, correct pattern:

#include <stdlib.h>

// Assume 'ptr' points to a valid, dynamically allocated block
// and we want to resize it to 'new_size'.

// 1. Store the result in a temporary pointer
void* temp = realloc(ptr, new_size);

// 2. Check for allocation failure
if (temp == NULL) {
    // Reallocation failed.
    // 'ptr' is still valid and points to the original block.
    // You can now decide how to handle the error.
    // For example, log an error, free the original memory, and exit.
    
    printf("Error: Memory reallocation failed.\n");
    free(ptr); // Clean up the original block before exiting
    // exit(1);
} else {
    // 3. Success! Update the original pointer to the new address.
    ptr = temp;
}

The following video provides an excellent walkthrough of these scenarios, culminating in the safe pattern using a temporary pointer.

This safe-handling pattern is also clearly documented in the following article. It's a fundamental technique for robust C programming.

#include <stdlib.h>
#include <stdio.h>

// A struct to manage our dynamic array
typedef struct {
    float* data;
    size_t count;    // current number of elements
    size_t capacity; // allocated capacity
} SpeedLog;

// Faulty implementation
void add_speed_reading(SpeedLog* log, float speed) {
    if (log->count == log->capacity) {
        // Time to grow the array
        size_t new_capacity = log->capacity * 2;
        log->data = realloc(log->data, new_capacity * sizeof(float));
        log->capacity = new_capacity;
    }
    
    // Add the new speed reading
    log->data[log->count] = speed;
    log->count++;
}

An Authoritative Answer: The C Standard

A common follow-up question is: "If realloc succeeds by moving my data, do I need to free() the old pointer?"

The answer is unequivocally no. The C standard itself provides the final word on this.

The two key takeaways from the standard are:

1. "The realloc function deallocates the old object pointed to by ptr..." — This means on success, realloc does the cleanup for you. Freeing the old pointer yourself would cause a "double free" error.
2. "If memory for the new object cannot be allocated, the old object is not deallocated and its value is unchanged." — This confirms why the temporary pointer pattern is essential. On failure, you are still the owner of the original block and are responsible for freeing it eventually.

Conclusion

You've now learned how to dynamically resize memory allocations, a powerful technique for creating flexible data structures. More importantly, you've learned how to do it safely. For someone in your field, where software robustness is paramount, internalizing this safe pattern is non-negotiable.

Key Takeaways:

• realloc(ptr, new_size) changes the size of a memory block, returning a pointer to the (potentially new) location.
• A successful call might move the entire block, so you must update your pointer with the return value.
• Always use a temporary pointer to store the result of realloc. This allows you to handle allocation failures gracefully without causing a memory leak.
• On success, realloc automatically frees the old memory block. You must not free it yourself.
• On failure, the original memory block remains valid and allocated. Your program is still responsible for managing it.

Preview of the Next Lesson:
The errors we've worked to avoid today—memory leaks and potential double-frees—are part of a family of common and dangerous pointer-related bugs. In our next lesson, we will systematically address these issues, learning to "Identify and prevent common memory errors such as double-free and use-after-free." This will equip you with the defensive mindset needed to write truly reliable C code.