Why realloc can cause memory leaks: return values and ownership checks

realloc can lead to memory leaks, primarily due to directly using the return value to overwrite the unique original pointer: when a non-zero size reallocation fails, the old memory still needs management, and the original pointer is lost. Another risk arises after successful movement: pointers pointing to the old block or within it cannot be used as before.

First define which interface is under discussion

We'll now discuss the non-zero size request in the standard C `realloc`: when allocation fails, the old object is not released. In actual engineering, it may also use encapsulated functions or macros with their own failure conditions, allocator choices, and zero-size behaviors that need to be separately checked.

For example, Python's C API provides its own handling for `PyMem_Realloc`. One cannot equate a specific version of the Python macro definition with all platforms' `realloc` based on their names alone. Python Memory Management Documentation

Use a temporary pointer for success and failure paths

Here is an independent teaching example. We'll assume `*buffer` refers to valid memory or a null pointer that can be adjusted by `realloc`, and `new_size` must be greater than zero; in case of failure, the original memory will be held by the caller.

```c #include <stddef.h> #include <stdlib.h>

int resize_buffer(char **buffer, size_t new_size) { if (buffer == NULL || new_size == 0) { return -1; } char *temporary = realloc(*buffer, new_size); if (temporary == NULL) { return -1; /* original memory remains under caller ownership */ } *buffer = temporary; return 0; } ```

This function retains ownership in case of failure. The caller must decide whether to continue using the old buffer or perform cleanup and terminate operations; a failed return itself does not indicate that resources have been released.

The success path can also fail

If another variable tracks the block's offset, it should save a valid offset before adjustment and recompute based on the new address afterward. When reducing buffer size, one must confirm that offsets and subsequent accesses remain within the new boundaries. One cannot rely solely on a specific address not changing to continue using an old pointer.

If the new size comes from `elements * element_size`, it should be checked for integer overflow before calling. Zero-size requests are defined separately, such as by business explicitly releasing and setting to null to avoid relying on differences between various standards or implementations.

How to review the static-analysis finding

Check the original allocation, ownership transfer, return value overwrites, and all exit branches along the path. Expand on any encapsulated or macro usage. To determine if a specific project is truly leaking, one must also consider version, source code location, and reachable conditions; screenshots from tools are not enough to replace these evidences.

Is Shrinking Memory Always Successful? One cannot assume so; handling return values is still necessary.

Are Temporary Pointers Enough for Safety? You Still Need to Check Size Calculations, Old Aliases, Ownership, and Final Release. The Example Only Addresses the Issue of Losing the Unique Original Pointer in Case of Failure.