If you are following the C standard for malloc(), then realloc() comes along. In fact, according to the C standard, malloc(size) is the same as realloc(NULL,size) and free(ptr) is the same as realloc(ptr,0).
realloc() can also shrink a previous allocation, in addition to growing it (but you must be aware that you might get back an entirely new pointer).
Which is why you might get back a new pointer---because the original block couldn't be grown, so a new block has to be allocated and the contents copied.
>but you must be aware that you might get back an entirely new pointer
Which is super fun if someone else adds code that keeps a copy of the pointer, not knowing that it might change.
Incidentally, is that possibility realistic in a 64-bit system? It seems like the addresses could easily be spaced out enough that you would never actually expect to see a realloc return a different pointer.
They could, but it would be extremely inefficient for small allocations. Pages are 8 KiB minimum, so it would waste memory, bloat up the page tables, and ruin cache efficiency.
Hmm, I see what you mean. But it seems like that could be solved by more sophisticated virtual memory management, although it seems like it would essentially take an entire other layer of virtualization to make it work, which might have other performance consequences.
For example, jemalloc stores medium-sized allocations in big contiguous buffers, binned by size rounded up to 16 bytes. So if you realloc to a different size class, your pointer will change, because you need to move to a different big buffer.
A custom allocator may gain efficiency by optimizing explicitly for or against the realloc() scenario.